> 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
