On 14 Nov 2010, at 16:10, tlaro...@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 (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
