Die GNU autotools

[Elazar Leibovich]

For the sake of the brevity, I'll summarize the claims I heard, and reply to
them:

You still didn't bring good enough example, if only the Go project was more
> complex, they would benefit so much from the autosuite/ they have a really
> bad build system now, it causes so many problems.


I won't argue with that. The fact is, that the Go programming language is
relevant and working now on various platforms. I'll let the wise reader to
judge if it's good enough. Remember the philosophy, it has to work OK for
99.9% of the use cases. I just want to assure you I'm not the only one using
go ;-).

Autotools are easy for the client. Just as easy, or easier than any other
> solution, so what's all the fuss?


When everything is working correctly, it doesn't matter which build system
you use. When there are troubles it is extremely hard to debug an autosuite
based project, in contrast to makefile based project. I've had problems with
makefile based build systems before and they were easy to solve. I usually
decided to bypass problems I've had with autosuite based builds.

Now I want to quote Nadav in order to demonstrate the wrong-nowadays (IMHO)
philosophical approach of the autosuite

At that point, I'd been

developing this software for almost a decade, and had run it on more than

a dozen different variants of Unix, and many versions thereof, and I've

accumulated a big ugly Makefile and a big ugly INSTALL instructions, which

you needed to follow to compile it. Were you using ANSI C? Set this flag.

Were you compiling on AIX? Set that flag. Do you have matherr(3)? gamma(3)?

Did your C compiler had a specific bug that was only found on one specific

machine? Were you using Bison or AT&T yacc?


That's exactly my point! Wondering if your user have matherr(3) or gamma(3)?
Don't use it! In a modern system you'll have alternatives for that.
Wondering whether your user has Bison or AT&T yacc? Use bison and drop yacc
support, in a modern system you can expect bison to be supported.
But whatever you do, do NOT set compile time flags in your software. They
should be in a compatability layer you should use, not in your code. It will
come back and hunt you.

Look at the legacy OpenVMS I have in my workplace, we need to support it,
> and it only has the Metaware compiler. Only the autosuite would come to
> rescue in this case.


Listen, autosuite is not a magic powder you mix into your project, and TADA!
it compiles against all legacy unices. You still need to compile run and
test the code on this platform. And nowadays, there is a small amount of
platforms which are relevant to your software, and you're probably not going
to invest the time in order to make sure it works there. So if there *is* a
special platform you need your software to work on, your best bet is to
stick to as standard C as you can, and make the build system dead simple, to
make compiling it easy on this platform.

I've been in this business for 10 years, and I tell you kid, you aint know
> nothing.


But that's my point exactly! When you were in this business, the relevant
targets were much more scattered and limited than nowadays. It is no longer
the state, modern system are much more standardized, and those who don't are
not interesting enough. jwz avoided templates in C++ because they weren't
widely supported then[*] can you imagine doing that in a modern software?

[*] http://www.jwz.org/blog/2009/09/that-duct-tape-silliness/
--
Example specific claims
--

> Would Go also compile Solaris? On AIX? On True64 UNIX (if you happen

to have an Alpha machine)? On various versions of
> Fedora/Debian/Ubuntu/Gentoo

from the last 10 years? You can say you don't care, but I do.


1) I think that in modern machines where gcc/gawk can run on, it is very
likely to compile.
2) I'm not sure that in this case (ie, gcc is running on the machine)
autotools would make much difference.
3) The main reason that Go might not run on this machines, are lack of
testing, and not a bad building system.
4) Even if autosuite will save some time, testing and maintaining the
software on so many systems will cost so much more than the cost of
maintaining the build system. Here is a summary of the problem with porting
Go to Solaris. Automake won't solve any of them.

https://groups.google.com/group/golang-nuts/browse_thread/thread/2f4f9ceb9cd933a4

Go needs a special directory structure/environment settings


At least now it doesn't need directory structure to compile. It does need
two environment variables to compile, but they are the equivalent of a
'./configure --to-ARM' command (ie, impossible to figure out automatically)
so I'm not sure it's such a bad thing.
Anyhow, from my personal experience, builiding Go is very easy and
straightforward.

ANT is bad, because...


I only brought the ANT and the godag examples, as things which makes
building simple things simple, in contrast with autoscan which makes
building simple projects difficult.

Just as an example, consider the Apache Lucene project, a very useful Java

search-engine library. Would you believe that until the end of 2009, Lucene

had officially stuck to Java 1.4 and could not use any new Java 5 features,

even conditionally? Remember that Java 5 had come out 5 years earlier...


Huh? And having #ifdef JAVA5 sprinkled in the code looks like a better idea?
Yes, having a branch for Java 1.4, and a different branch for Java 1.5 looks
like a great solution, much better than choosing it compile-time with
autosuite. Eclipse does just that, and I didn't hear any complaints.

Project like the kernel MUST choose their component in compile time.


The kernel is not that great example, because most of us are using stock
kernels (exaclty because having a single binary makes it easier to debug
problems in customer's boxes. I know exactly what was compiled into your
stock RHEL 5.3 kernel, so it easier for me to figure out the problem).
But indeed you must have an autotools like capability with project like the
kernel. Does that means that this is a good idea in general? Does that mean
that if I'm writing "hoc" today I'd better of use the autosuite? I really
think not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110112/c168dd8d/attachment-0001.html>