Re: LYNX-DEV BSD makefile support 8

[Bela Lubkin]

Michael Sokolov wrote:

>    But let's get back to the Makefile issue... I see you saying that the
> autoconfigure script produces a Makefile that one can verify and modify if
> necessary. However, I claim that it is much more productive to do this with
> a static Makefile than with one that's auto-generated each time.
>    Suppose that I see a problem in the auto-generated Makefile. I fix it
> and get that version to compile. When the next version comes out, or when I
> need to install Lynx on another machine, I have to do it again. Similarly,

Here is your error.  You should be thinking in these terms: if the
configure script generates the wrong makefile for your machine, you will
submit corrections to *configure*, which will cause it to create the
correct makefile.  Thus your work will not be lost, regardless of
whether the mechanism which embeds that work is "configure" or
"Makefile".  By "corrections to configure", I do not necessarily mean
that you-Michael-Sokolov will have to learn the internal workings of
configure; but rather that you will submit a functional description of
its misbehavior, and the maintainers of the autoconfig feature will fix
it.  (Unless, of course, you *want* to learn the workings of configure
and thus submit more specific fixes.)

> when another sysadmin has the same problem, he/she has to do it again too,
> even though I have done that already. With a static Makefile, on the other
> hand, a correct target can be added in a centralized fashion for everyone's
> benefit.

Exactly wrong.  Fixes to the configure script apply to all systems; e.g.
a test which determines whether "-lresolv" or "-lbind" is most
applicable to a particular system will help *all* systems that upgrade
to BIND 8.x.  A specific makefile target is only good for a system that
exactly matches the target.

A good example of this is the proliferation of "system:" vs.
"system-ncurses:" vs. "system-slang:" targets.  The configure script is
capable of writing a single entry that encapsulates the correct screen
library.  Static makefile entries must be multiplied by every possible
variation in target systems.  Bind 4.x vs. 8.x would undoubtably have
caused a further doubling of makefile targets, using the old system.

>    If you are concerned about the static Makefile growing to a jumbo size
> (about the size of your autoconfigure script) by supporting all possible
> OSes, think of it this way. One can write a target that covers a huge
> family of operating systems. For example, my pure 4.4BSD target covers ALL
> BSD-based (or West Coast) UNIX systems. A simlar target for pure SVR4 would
> cover ALL East Coast UNIX systems. These two targets together would cover
> ALL UNIX SYSTEMS IN THE WORLD, since all of them were at some point based
> on either BSD or SVR4 and when a system is based on some core, it normally
> retains compatibility with that core. For instance, FreeBSD and NetBSD are
> 100% downward compatible with pure 4.4BSD, and Solaris is 100% downward
> compatible with SVR4 (to the point that the logo says "SVR4" without even
> mentioning Solaris). Thus you don't have to support all possible OSes or
> try to automatically discern their nature, since just two static targets
> are enough to COVER THE WORLD.

Yeah, that's nice, except that it is PURE NONSENSE.  Lots of extant Unix
systems are based on SVR3.x (AIX, HP-UX, A/UX, SCO OpenServer); one is
based on OSF/1 (Digital UNIX); the largest family of all is genetically
unrelated (Linux).  Even the SVR4-derived targets in Lynx's Makefile
differ -- "svr4:", "unixware:" and "solaris2:" are all sufficiently
incompatible to require their own entries.

>    And what about Larry W. Virden's suggestion that a traditional Makefile
> be kept but limited to those targets that have volunteers supporting them?

I personally think it's a bad idea.  It serves no purpose except to
encourage nonsense like this.

The configure script has been subject to over a decade of execution on
every possible Unix variant.  It runs on anything that could possibly
hope to be Unix.  It will therefore produce a makefile and lynx_cfg.h,
which -- if necessary -- can then be hand-edited.  The produced makefile
and lynx_cfg.h are either *right*, if it's a system that has been
deliberately targeted, or *close* to right, closer than would have been
possible in a makefile full of system-specific targets.  (Proof: if
there had been a closer specific target, configure would have determined
the same things and produced such a target.)

> As I have said before, I'm willing to be such a volunteer. Moreover, since
> I know a lot about all BSD systems in general, I can extend my
> responsibility to close (BSDI, FreeBSD, NetBSD) and distant (SunOS)
> "relatives" of BSD and not just the pure 4.4BSD.

How about OpenBSD?  Next year's splinter group?  Having led the BSD
users of Lynx into a backwater ghetto, are you really going to fix all
the resulting problems forever?

Please answer these two simple questions:

  1. HAVE YOU RUN the configure script (`./configure; make -f makefile
     generic`) and tested the results?

  2. If so, and if the results were unsatisfactory, exactly WHAT WAS
     WRONG?

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