Re: lynx-dev overuse of system-specific conditionals (was: cygwin patch)

[Doug Kaufman]

On Mon, 1 May 2000, Klaus Weide wrote:

> But these choices shouldn't be hardwired into the source code in such
> a way that it gets near-impossible to disentagle them, for someone who
> looks at the source code (and perhaps doesn't even know what DJGPP or
> CYGWIN is).
> ... 
> I mean, "don't use cp in a cygwin environment" is a preference, a choice
> you made, not something that is required to run in a cygwin environment.
> You think it's more appropriate as a default, and I have no problem with
> that (but some questions, see below).

Point taken.
  
> > Indeed, the SH_EX changes are Senshu Hiroyuki's preferences, which
> > have not yet been accepted for general use. 
> 
> As well as WIN_EX?

I thought that the difference between SH_EX and WIN_EX was that the
latter was thought to be generally acceptable code for use in Windows
platforms. I must admit that I wasn't paying that much attention,
since I wasn't using cygwin at the time this was discussed. I am
not sure who accepted the WIN_EX code. Was it Hiroyuki who made the
original decisions? I, at least, was hampered by the documentation in
Japanese, and have trouble reading through the code to decide what it
does and why.
  
> Anyway, I'd say don't be afraid to add a new preprocessor symbol
> where it makes sense.  They don't all need to be exposed in userdefs.h
> or in the makefile(s).  For example, for the "use cp or not" question,
> something like
> ... 
> would be better than the current situation.  That #define could be just

> > Since most Windows users wouldn't have cp, this saves the need to
> > distribute a compatible cp with the lynx binary.
> 
> Most Windows users wouldn't, but what about "most Windows users with
> the cygwin library installed"?

All you need to run cygwin ports is a copy of cygwin.dll in
C:\WINDOWS\SYSTEM. No other files should be necessary, so I don't know
that you can assume that a user of a cygwin port has GNU fileutils or
textutils installed.
  
> (How "standalone" can a cygwin port be?  Users need to install the cygwin
> stuff if they don't have it already; and if they do, won't they have
> a working 'cp', too?)

See above.
  
> > I haven't recommended putting them in, and haven't in my personal
> > compile. See, howver, the LYSystem code in LYUtils.c when DOSPATH and
> > __CYGWIN__ are both defined.
> 
> That's a horrible and undocumented hack IMNSHO.  If I were using lynx
> for a cygwin environment, I'd want to make damn sure that this code isn't
> compiled in.  It looks like an attempt to fix some symptoms instead of
> ... 
> No-one who compiles lynx should get this code without explicitly
> requesting it.  It should depend on some '#ifdef SYSTEM_COMMAND_FOR_
> DOS_HACKS', and 'defined(__CYGWIN__) && defined(DOSPATH)' should not
> be taken to imply that one wants this.

How many other places in lynx have platform-specific code that was
introduced without full evaluation?
  
> > I think the cygwin port is still very much more like unix than like
> > DOS or Windows.
> 
> Does that mean it falls short of the
> 
>    different binaries for the same platform (i.e. Borland or cygwin
>    compiled) should have compatible user interfaces
> 
> goal?

Of course. That is one of the reasons that I haven't made the cygwin
binary available for distribution, yet. I suspect that most users
who had to specify local paths as "/d/whatever/foo.bar" instead of
"D:\whatever\foo.bar" would just remove the program as unusable.
  
> > I am not sure how many of the defines are not required by the
> > platforms for binary handling, pathname handling, or TCP handling.
> > I suspect that very few represent personal choices between viable
> > alternatives, but I haven't looked closely at them. 
> 
> Maybe it's time, now that 2.8.3 is out, to risk breaking something.
> Let them complain (or help with the cleanup).

I'll try to put looking through the code for questionable
DOS/CYGWIN/WINDOWS items on my TODO list, but time for this is
limited.
  
> > Does anyone
> > have any suggestions on clearing this up some before 2.8.4 gets
> > released?
  
> - For any new patches that would use conditional code with one of
>   those symbols (__DJGPP__, _WINDOWS, __EMX__, __CYGWIN__, etc.),
>   or change them around: question what is really meant, what the
>   patch is trying to achieve.  Then express than in term of
>   meaningful feature or behavior macros.

This sounds reasonable (actually for all patches).

> - (Somebody should) Clean up DOSPATH usage!
>   Grep for DOSPATH in all source files.  Separate all tests where
>   DOSPATH is used for something else than file path syntax from the
>   rest.  Leave the latter as DOSPATH, change the none-path-related
>   occurences to something more appropriate (as a first cut, just
>   something like OTHER_DOSISH_BEHAVIOR if there's no obvious more
>   specific description).  In most cases, the determination whether
>   the conditional code deals with path syntax or other aspects is
>   easy to make.

I don't think I have the time or expertise to do this.

> - In particular __EMX__ likes to occur in combination with DOSPATH -
>   as in
>               defined(DOSPATH) || defined (__EMX__)

Is anyone compiling lynx for OS/2 now?

> - Repeat for __CYGWIN__, maybe others.

I'll try to look critically at some of these when I get the time.

Are there comments from others who work with the DOS/WINDOWS/OS/2
ports?
                             Doug
__ 
Doug Kaufman
Internet: address@hidden