Die GNU autotools

[Nadav Har'El]

On Wed, Jan 12, 2011, Elazar Leibovich wrote about "Re: Die GNU autotools":
> 3) Have a project in a separate directory which implements an efficient map
> in a siusing existing map implementation. For this project, it makes sense
> to use autotools. But this project will provide a solid testable interface
> (ie .hpp file) for this map.

So basically, you're proposing that one big project with a complex autoconf
setup is split into many different subprojects (libraries), each with its
own autoconf setup? This suggestion may be valid in certain cases, but
you're still ending up using autoconf - perhaps even more of it...

At the end, some piece of code needs to check, at build time, whether the
system's compiler and libraries already include a map implementation, or
they don't. Autoconf (and its heirs to the throne, mentioned by others on
this thread) does this pretty well.

> This way, my main project have a straightforward build system, and the
> portability layer is isolated from the project, testable and more portable
> (what if we'll have a platform with buggy std::map implementation we can't
> use? In case of (3) we can easily borrow one, and change the portability
> layer only. What would the ng-fakeroot project do for such a system?).

What do you do if you have a realtively small project (not something like
OpenOffice) and you find yourself with 7 different "portability layers"
for all sorts of small features like this - do you really prefer having
7 different libraries, 7 build systems, 7 different "separate projects",
and so on, compared to what Shachar described - simple #ifdefs that solve the
problem?

> What about the case of inotify/Linux fragmented audio system, etc, etc.?
> Again, the autosuite won't save the day here. If I want to write a portable
> program which uses inotify (which is kind of oxymoron, as inotify is a Linux
> specific API), what I really want is to program to a layer of abstraction
> above inotify, which is portable to as many system as possible. If I don't

You're basically saying the same thing I am, but reaching a different
conclusion. Indeed, a portable program can't rely on inotify because that
is only available on Linux, and only certain versions thereof. When inotify
is not available, it needs to resort to other mechanisms which might be
available, and when all else fails, resort to slow-and-ugly polling.
Certainly, and sensible program design will wrap all these options into one
function or library inside this project, and use this function throughout
the projects. Still, when compiling this function, somebody needs to choose
whether to compile inotify code, or one of the other options - and this
somebody is autoconf (or one of its competitors). If you compile this
function-or-library separately, basically nothing changes - you still need
to make decisions at compile time.

> would encourage me to write an ad-hoc half-broken portability layer with m4,

Unless you need to invent completely new kinds of tests - and in 99% of the
cases you don't - you don't actually need to learn m4 to use autoconf.
I do agree that m4 is ugly and was an unfortunate choice.


-- 
Nadav Har'El                        |     Thursday, Jan 13 2011, 8 Shevat 5771
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Love doesn't make the world go round -
http://nadav.harel.org.il           |love is what makes the ride worthwhile.