Re: Auto-tools & Win32 & Borland C++ Builder

[Tom Tromey]

>>>>> "Martin" == Martin Hollmichel <address@hidden> writes:

Before I address your points, or at least the ones I plan to address,
I thought first I would write my own critique of the auto tools.
While I do think that these tools have deep problems, I also think you
largely avoided mentioning them.

The most visible problem with these tools is complexity.  In part this
complexity is justified; configuration and building is by nature
complex.  However, some of this complexity occurs for reasons having
to do with design and implementation choices; that is, features of the
solution and not the problem.

For one thing, the reliance on very few Unix tools is crippling.
Portable sh is very limited indeed, and adds greatly to the amount of
knowledge and the time required to write a portable configuration
environment.  Worse, this cost is distributed not only throughout the
tools themselves, but to the users of the tools.  Likewise, reliance
on the portable subset of `make' means that automake, and its input
language, are quite constrained.

On top of the deficiencies of sh and make is the fact that you also
get to deal with m4.  So now there are 3 quoting discipline: sh, m4,
and make, and you get to mix and match them.  There are more problems
along these lines which I won't go into.  I'm sure anybody familiar
with the tools has run into them.

Another contributing factor to the complexity is rooted in the
historical design of the tools.  They were not designed as a whole,
but were instead designed and built in pieces, by different people.
Nobody who set out to design a configuration/build system would come
up with the auto tools.  It is a bizarre solution, driven by
particular historical, technical, and political needs.


I think I can also come up with a coherent picture of what a nice
design would look like.  In my plan, we avoid make and sh and m4
entirely.  We have a single tool that integrates configuration and the
build.  This is quite a change, but the result, IMNSHO, looks quite
pretty: a package expresses its dependencies, not only in terms of how
it is to be built, but also in terms of what configuration information
it needs.  Changes to the configuration or build environment result in
minimal re-configury.  Etc; I could go on in great detail about the
idea but I won't right now.


On to your complaints.

Martin> I think the great misunderstanding is that the autotools are
Martin> not targeting real multiplatform development, but Unix centric
Martin> distribution of (GNU) OpenSource Software.

Often times people seem to get annoyed that these tools don't do what
they expect.  This is usually a bug in that person's expectations.

Historically these tools were Unix-only.  In the recent past there has
been some attempt to include Windows (particularly via Cygwin; I've
had a lot of success with that).  I don't think people pretend
otherwise.

Martin> * changing a autotool file, then waiting for configure to
Martin> write 1200 makefiles.

Yes, that's a problem.  In fact build times in general are a problem.
Some of this is due to the auto* model.  Some of it is due to the
inherent lameness of make.

Martin> * Mixing up debug and non debug build, do both causes double
Martin> compile time, double diskspace and x-time more RAM for the
Martin> debugger. Imagine to need 10 GB for Openoffice debug build and
Martin> more than 2GB RAM to start the result in a debugger.

I don't understand this.  Do you have a system where you can do a
debug build and a non-debug build that doesn't take more disk space?
I don't understand what the debugger has to do with this discussion
either.

Martin> * try to build a four year old glibc on a two year old Linux
Martin> system or vice versa. You have to begin to hack a
Martin> configure.in.

Maybe that is glibc's problem.  Another phenomenon I occasionally see
is that people blame deficiencies in a given configure script, or a
given Makefile.in, on one of the auto* tools.  Sometimes this is
warranted, sometimes not.  If somebody writes unportable C code, do
you blame the compiler?

Martin> * using 30 year old preprocessor technology is not the most
Martin> comfortable way of doing Software Configuration Management
Martin> (SCM) and script development.

If you're trying to say that m4 was a poor choice for autoconf, then I
agree.

If you are instead saying what you wrote, namely that the age of m4 is
somehow relevant to its usefulness, then I disagree.  I don't think
the age of a tool is a particularly good predictor of anything.

Martin> Anybody who like to give hints to use autotools for
Martin> OpenOffice.org ?

>From what you wrote it sounds like you don't want to.  Why aggravate
yourself trying?

Tom