Die GNU autotools

[Elazar Leibovich]

I'll emphasize, I did not say "autosuite is always bad". Autotools has it
uses (maybe a more modern implementation would be nicer, but nevertheless it
does the job).

But what I'm saying is,
1) Nowadays supporting some legacy systems is simply not cost efficient. And
supporting legacy systems will cost you much more than the cost of using
autotools, so think twice before deciding on supporting legacy systems (the
main use of the autosuite, it wouldn't really help you with inotify or
PulseAudio).
2) Do not use the autosuite, unless you are writing a portability layer.
Otherwise you'll mix the portability layer logic into your main application
logic, and this is bad. For example, in fakeroot-ng, how will you test and
make sure your map is efficient enough in your platform? This logic will
have to be in your main project in the current design.
3) Using autotools have it costs (mental tax, lengthy configuration,
different code on different systems), so if you can avoid it - please do.
Even if that means you'll copy another implementation to your codebase or
supporting less platforms.

As a result I conclude, that if your project goal is not to provide a
portability layer, it should not use the autosuite.

For instance, in the std::map example, having the efficient map abstraction
coupled to your main project, and underdocumented (which platforms do the
effecient map support? Which compilers does it support. Does all compilers
implement unordered_map to as effecient as I require? What are actually my
effeciency requirement (if I don't know then I can probably just use
std::map)).
All this portability-related information is hidden in the m4 files, and
coupled to my project. If I keep the rule that my main logic will never use
autotools, then I'll have a different small portability layer which is less
coupled to my project, and whose main goal is to be portable. So I'll write
proper test to the new map (which I'll tend not to do if it's just an m4
file in another big project), will state exactly the requirements. I'll have
a real class with a solid interface (the .h file is the same on all
platforms), and only the implementation will contain the ifdef's, so that
I'll never use a method which is not availible on all platforms by mistake,
etc. etc.

So yes, I'd rather have 7 different portability layers, which are good, then
7 different portability layers which are coupled to my project, are ad-hoc,
under-tested and under-documented.

As a side note it sounds weird that your app need 7 portability layer, since
if something is really usefull, there probably is a portability layer
someone else has written.

On Wed, Jan 12, 2011 at 11:38 PM, Nadav Har'El <nyh at math.technion.ac.il>wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110113/bcf30931/attachment-0001.html>