[out of topic] RE: [tex-live] Build of Oct 2, 22:45 source.development fails onMacOS X

[Fabrice Popineau]

> HAVE_GETENV_H: "This machine has the getenv.h header"
> HAVE_DECL_GETENV: "This machine has a declaration for getenv()"

+ HAVE_GETENV, which makes 3. This new 3 symbols scheme has been introduced
into some recent GNU packages apparently. What I regret is that when such
changes are made, they are not propagated to all the GNU packages. You could
expect to put the whole set of packages side by side, run your configure
stuff and get something homogeneous. But it does not work like that. 

Somehow, it was one of the differences between FreeBSD philosophy and Linux
philosophy (at least somewhere in the past): you could assemble Linux by
getting components (binaries) from various places without guarantee that
they were made to run together whereas FreeBSD had a release scheme and the
whole stuff (of a given version) is compiled from the same source tree. 

On the other hand I had something quite similar happening here. I had
colleagues wanting to play with the common c++ library and libxml on .Net.
They compiled it using the provided VC++ projects and tried to use it on
another machine. For some unknown reason, it failed to link the simplest
program because of a missing destructor. Probably the compilation
environment for the DLL was different from the one where they tried to
compile the test application. But my point is: VC++ projects are complex
(hideous?) stuff, very painful to look at because you need to endlessly open
dialog boxes to check the parameters.

My point: this library compiles into a dll using a simple command line. So a
simple makefile would have been more appropriate than anything else.

> > But anyway, my point was: who ensures the stability of this set of
> features?
> 
> Us?  :-(

Frightening, isn't it ?!

Fabrice