Die GNU autotools

[Nadav Har'El]

On Wed, Jan 12, 2011, Elazar Leibovich wrote about "Re: Die GNU autotools":
> 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.

This is easy to say when I gave you as examples things which have been
decided long ago, and today 99% of the systems use the same thing.

But what if you want to support that 1% using some wierd or old system?
And what about newer features which the verdict isn't yet out?

Just as an example, consider optional features like poll/select/epoll,
esd/arts/pulseaudio, inotify/dnotify, ipchains/iptables (I hope you are
familiar with at least some of these), that during the (relatively)
recent past have come and gone in mainstream Linux systems (forget
all the esoteric Unix systems I mentioned). 

You can assume that today all systems have epoll, pulseaudio and inotify.
But what about a system from last year that still doesn't use pulseaudio?
(and this is of course just an example).

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

Looking back at software I have written, many times you simply have no choice.
You can only go so far with the "use the lowest common denomenator" approach.
At some point you want to start using features only available on some systems,
or features that due to bugs or other reasons behave differently on different
systems. Some things you can check in runtime, but some you can't: If you
are compiling on a system that doesn't have inotify, it won't have
#include <sys/inotify.h>, and you won't even be able to compile a function
that attempts to use it - so you cannot just try to use it at runtime and
see if it works!

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

This is 100% true. But the issue is, once you try to compile on a different
system (be it a different Linux distribution, a different version of a
familar distribution, a type of Unix, etc.) and you discover a compilation
problem or a special fix you need to make, autoconf allows you to write
this fix and make it automatic - so that whenever somebody compiles the
software again and faces the same difference (not necessarily on the same
system), the solution is already there.

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

Yes, do this and go buy some Intel stocks as well, because you are assuming
they will remain a monopoly.

> 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

This is definitely true, but it doesn't mean there is zero diversity today.
There are still many types of Linux distributions with their own peculiarities,
and you know what - I'm writing this mail on Solaris ;-)

And personally, I'm hoping that in the future, we'll have more diversity
again.

> 2) I'm not sure that in this case (ie, gcc is running on the machine)
> autotools would make much difference.

It did - because even if you were using gcc on these systems (and I often
did), you still had your own system's include files and libraries - most
of them did not come from gcc. Remember that glibc is a separate project,
and it is only available for Linux.

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

Thanks, I really need to try it again - about a year has passed since I
last tried it, so maybe things indeed improved.

> Huh? And having #ifdef JAVA5 sprinkled in the code looks like a better idea?

Yes - because this we they could have optionally used Java 5 stuff when it
made things better or quicker, but stick to the common Java 4 in most
places.

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

Actually, the Linux kernel doesn't use autotools ;-)

It assumes that the compilation system is a familiar GNU/Linux setup, and
won't work at all on other Unix versions, C compilers which aren't recent
versions of gcc, and so on.

-- 
Nadav Har'El                        |    Wednesday, Jan 12 2011, 7 Shevat 5771
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Hospital: Where they wake you up to give
http://nadav.harel.org.il           |you a sleeping pill.