Re: LYNX-DEV Re: is lynxrp.zip working /slang and color choices

[Klaus Weide]

On Thu, 31 Oct 1996, Foteos Macrides wrote:

> Klaus Weide <address@hidden> wrote:
> >On Thu, 31 Oct 1996, Nelson Henry Eric wrote:
> >
> >> > > > > Had trouble compiling because of the `$(STYLE).o' line in
> >> [...]
> >> > > sunos4.1.3/ncurses-1.9.9e/gcc-2.7.2
> >> [...]
> >[Rob Partington:]
> >> > Are you using GNU make?  If not, that might be the problem.
> >> 
> >> No, I'm still using Sun's (wherever they ripped it off from).  If it is
> >> dependent on what `make' you are using, then I couldn't recommend such
> >> syntax in the Makefile because it will narrow the prospective user base.
> >
> >A specific make shouldn't be required to compile Lynx, unless that change
> >would be of tremendous benefits (which I don't see).  But Rob may just
> >not be aware of it when he uses GNU-make-only constructs in his code,
> >so it would probably help if non-GNU-make folks could point out what
> >exactly he should not use.  
> 
>       Note, however, that an upgrade to the v5 W3C Reference Library
> and it's use, now, of autoconf, in turn makes use of the GNU make a
> requirement (or so the v5 Library's docs claim 8-).  

Maybe yes, *if* we want to follow *exactly* what the W3C Lib is doing,
and do everything like they do.  I don't see any good reason to do that,
I would rather prefer a gradual approach:  let autoconf create the sysdep.h
file (or a file to be included there), with all the system dependent
#includes and #defines; let autoconf not anything to do with manipulating
Makefiles (at least in the installation process).  The autoconf-generated
Makefile from the current W3C Lib doesn't deal with such system dependent
stuff anyway, just with file dependencies, directory paths (install-dir 
etc.), and definition of some commands like CC.

> The previous
> K&Rizing, and use of platform/flavor #ifdef'ing, was geared toward
> what we have now in Lynx -- attempted support for every platform/flavor's
> native compiler and make (or .com's and/or MMS on VMS).
> 
>       The claim that such a change would "narrow the prospective user
> base" needs to be understood, thought through, perhaps tested, overtly
> (IMHO).  

It would be best to avoid a situation where the following kind of response
would become common on lynx-dev:
   "Ah, you have the XX problem.  There's a fix for that in the
    YY {version,patch}.  Just apply it. --- Hmm, I forgot, you are
    using ZZ... Sorry, Lynx 2.6 is the last version supported for
    your {system,environment,compiler}.  You will have to retrofit
    those latest fixes into the old code yourself, so sorry..." 
(IMHO).

Your suggestion of "overt testing" is probably meant to avoid just
that, but I can't see how it really can, as soon as some uncompatible
change has been made, and _that_ code becomes the base for new fixes and
extensions while it has not been tested on _all_ possible systems where
Lynx previously would compile...

Besides, I think it should be made clear that

- supporting GNU make only
- cleaning up platform-dependent #ifdef'ing and #including,
  possibly with help of GNU autoconf
- "to un-K&Rize or not to un-K&Rize?"

are three different topics, and one doesn't force the others.
At least in my understanding.

>         It had been by own assumption the previous time autoconfing
> was proposed, but that was before the Reference Library developers
> decided that "anybody" could get the GNU make, so the change won't
> "narrow the prospective user base".  

Sounds a bit like "Anybody could get Netscape Navigator or MSIE, so the 
change to use <insert favorite text-unfriendly HTML abomination of-the-week> 
won't narrow the prospective user base."  Maybe it sounds just like it on
the surface, or maybe it actually has something to do with the mindset,
sombody else figure it out..

Anyway, not everybody has NN or MSIE (whether they could easily get it
or not is not relevant), and not everybody has GNU make (and may have
their own good reasons for it).  Everybody who would install Lynx on a
Unix system presumable has a shell that could run an autoconf-created
./config script, so creating an installation procedure that uses
./config for system-dependent header files, but not for Makefiles,
makes sense.  IMHO.

> Which assumption is correct?

Dunno..



;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;