Re: [9fans] Plan9 development

["Gary V. Vaughan" <gary@vaughan.pe>]

[-- Attachment #1: Type: text/plain, Size: 4031 bytes --]

On 14 Nov 2010, at 16:10, tlaronde@polynum.com wrote:
> Hello,

Hi Thierry,

> On Sun, Nov 14, 2010 at 09:17:46AM +0700, Gary V. Vaughan wrote:
>> [[resent from my subscribed email address after the mailing list rejected the original]]
>> 
>> [...] 
>> AFAICT, without rewriting the entire GNU build system from the ground
>> up (and there is far too much momentum behind it to ever gain enough
>> traction to switch the GNU eco-system to an entirely new and different
>> build system anyway) the following precepts are immutable:
> 
> It took me less time to write R.I.S.K. (the building framework used
> for KerGIS and KerTeX)---and R.I.S.K. does shared libraries if supported
> and desired---from scratch than to try to understand auto*
> and libtool. Furthermore, the auto* and libtool were typically made
> for trying to do something "working" to some extend with a chaotic
> source. They typically manage to compile "things" written by
> programmers who have been encouraged to look at the finger ignoring
> the moon: to concentrate on the "GNU" tools and "GNU" libraries
> etc, and not on C89 (or C99), POSIX etc.

I mostly agree with everything you say here.  However, please try not
to confuse libtool (essentially a wrapper for vendor compilers that
allows developers to use the uniform ELFish conventions of the libtool
interface, rather than jump through the various peculiar vendor compiler
hoops for each new platform) with the GNU build system as a whole.  Note,
that Libtool actually works rather well in isolation, and doesn't rely
on the rest of the GNU build system to be useful.

> Furthermore, the tools were not written with cross-compilation in mind:
> compiling and testing a program to run it for obtaining an information
> is making the assumption that MATRIX == TARGET. Cross-compilation allows
> you to build with some assumptions and some warranties (on the MATRIX)
> for a TARGET that has perhaps not, by itself, all the utilities you are
> assuming.

Not true.  Auto* makes a valiant attempt at supporting cross compilation,
but when one's philosophy is "don't tabulate platform differences per
portability issue per vendor per release; actually check what the real
behaviour is"... and there is no runtime for the cross-environment on
the build host, what else can you do?  Auto*, in that case makes a
conservative guess, and allows the user to override it incase they know
better.

I think that's starting to get off topic though.

> The main problem is indeed "philosophy": encourage the bazaar even in
> the code. I personnally don't buy that. And the acronym "GNU is Not
> Unix" is a sophism since GNU will be strictly nothing without Unices,
> especially open source ones. But since GNU is not Unix, there are
> imbeciles that insist that a real GNU system must not conform to POSIX,
> because it is a Unix thing, neither to a C standard ([scornful]: if you
> really want this my dear, try "-pedantic"...).

In light of that, maybe you can suggest a better means for GNU Libtool
to prod the build environment and figure out what the characteristics
and limitations of shared libraries that need to be accounted for will
be?  Obviously, following the Auto* philosphy, we currently try out each
of the things we care about to see how they work, and then keep a record
of the results in order to build the libtool runtime script for
installation.

Does your build system work correctly with shared libraries in Mingw,
cygwin, AIX, HP-UX (to name just a few of the more awkward under-
featured shared library implementations I care about) under various
compiler and library releases?  How did you do that without either
probing the environment (which is what we do already) or tabulating
known results (which breaks every time you encounter a new system, and
requires maintenance for every supported combination of compiler/libc/OS
if a new variable is added to the tabulation)?

Cheers,
-- 
Gary V. Vaughan (gary@gnu.org)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 202 bytes --]