[ On , September 1, 2000 at 11:13:04 (-0400), Paul D. Smith wrote: ]
> Subject: Re: HTML format documentation
>
> No. This is exactly the right way to do it.
>
> Autoconf should provide a well-defined set of directories, each with a
> well-defined purpose/policy, and each with a default value based on one
> global value (prefix) so they're simple to re-target en mass.
>
> Then it should allow users who care about such things to modify each
> individual value to suit their particular environment.
>
> That's all it should do.
That's all very fine and good in so far as it goes. however....
> People who have to place everything "just so" can easily read the
> INSTALL file and get the right options, or create a site config file, or
> whatever. Autoconf should make things simple for the clueless user, and
> make modification straightforward (e.g., no "magic guessing") for the
> advanced user.
Unfortunately the clueless user is faced with multitudes of clueless
developers, each with his own strong but unfounded opinions.
By giving ultimate flexibility in the way you describe the devloper is
also free to muck with the defaults and to make even greater mistakes in
mis-classifying the files he's trying to install. The result is that
the user cannot rely on a site-wide config file for autoconf because
every developer's products might require new and unique and/or different
settings in order that the result conform to the true system (or site)
policies.
If the goal of autoconf is still to make applications portable to
*different* kinds of sytems and platforms, and if autoconf is going to
not only help with compiling such applications but also with installing
them properly, then it is autoconf which must learn the proper defaults
for each kind of system -- it must not impose its ideals on the hapless
user, regardless of how well founded those ideals are, because it is
ultimately only in the user's advantage to maintain consistency and
regularity throughout any given system. If a user wishes to make
/usr/local appear the same on all his or her systems despite the chance
this will violate the model used on the rest of any given system, then
he or she should be well aware of the rats nest they are creating and
know how to deal with it. In the mean time I've discovered that
consistently users tend to put their HP/UX hat on when they work on such
systems, then switch entirely to their Solaris hat when they move over
to work on their Sun machines, etc. After all if such users wanted the
same environment on all their hardware then they've probably got at
least two choices for the option of running the same OS on all their
hardware!
Where "we" (i.e. developers in general) have gotten into big trouble in
the past has been when we try to mold existing systems into our
favourite image. Eg. when we put a /usr/local on a Solaris system. In
these more modern days most systems have at least partially defined
their filesystem layouts in their documentation (filesystem(7) on SysV
Unix, hier(7) on Research Unix and *BSD, etc.). I think it is in
autoconf's best interest to work towards honouring the defaults implied
by those documents.
For example If I define a new kind of system where there is no "/usr"
then I should be able to supply a patch for Autoconf that adjusts the
default $(prefix) to be "/" or "/local" (the latter choice depending of
course only on how well I think my users will be able to cope with
mixing add-on packages with system stuff -- eg. I may avoid /local if
I've got a fine-grained packaging system that can clearly identify all
native and foreign files, and especially if I normally provide wrappers
ala "ports"/"pkgsrc" for autoconfed packages so that they too enjoy the
benefits of this packaging system).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
