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

[Martin Hollmichel]

> 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.

Yes, you're right, I avoided that. if you're looking into such an 
environment there are many aspects you have to think about. Maybe we 
should do a discussion for what aspects of software development the 
autotools can be used for and what is missing for being are real 
development platform.
  
> 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.

Yes I agree, the complexity of the autotools is really big. This was the 
reason for asking for deeper documentation for these tools. Right now you 
get the most if you're looking into the source. This is a little 
difficult, because you have to know something about m4, make and sh 
syntax and because there are many tools this all is not much readable.

> 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.

Yes.


> 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.

Yes.

> 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.

Sounds good, maybe we should search a better place to discuss these.

> 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.

That's sooo true.

> 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.

I think this is one of the most urgent problems, it's Unix centric. We 
have with cygwin a Unix environment on Windows, but that not the whole 
truth. Since Windows have a great developer community with other 
development environment than Unix the autotools aren't really 
multiplatform. And I think at the moment the autotools don't want/can to 
support native non Unix platforms.

> 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.

There are two different models possible (plus a mixture of them) 1. to do 
all the configuration at configure time 2. or let the developer decide at 
developement time what he really want. That means that you're only do 
some base configuration at configure time and control with the help of 
variables the rest later.

> 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.

I want to explain that a complete configuration of the environment some 
doesn't make sense in every case (e.g. configure a debug build for 
OpenOffice.org, because this configuration is not feasable). I like to 
have platform independent switches at development time like make debug, 
because I cannot remember all the different debug switches for the 
different compiles I have to use (same for profiling, non/optimized and 
so on.
 
> 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 oneof the auto* tools.  Sometimes this is
> warranted, sometimes not.  If somebody writes unportable C code, do
> you blame the compiler?

No but's so easy to write non portable and dependend auto* code, espec. 
For non trivial project like glibc.

> 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.

No, the age of the tool speaks for using it, but to use a preprocessor 
for developing script is difficult.

> 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?

It has to do with expectations again, my users want to use the autotools 
and so I begun to take a closer look to the autotools and I discovered 
that they don't fit all our needs and that it is difficult to enhance 
them 
so that they meet the my expectations of a development environment. So 
right now I'm in a phase to look for arguments why we don't drop the 
existing environment and change to autotools, and I will start thinking 
of 
a new environment which take some advantages of the existing 
OpenOffice.org and auto* environment and do one more (maybe better) 
implementation. Autotools fits perfect for small unix based
software development but I want to look for developer friendly 
environment for bigger projects.

I know that the existing OpenOffice.org environment is far away from 
being perfect, but it is a successful environment for doing development 
on Windows and Unix in parallel and having same release dates of products 
for those platforms.

I think we all agree that one of the central ideas is to give a developer 
the possibility to create one script file (makefile) for all platforms 
and 
the he don't need to take care of to many platform dependent details (I 
hate environments which contains a makefile and a makefile.win and a 
makefile.mac, I don't want to maintain such scripts ).   

> Tom

Martin