Die GNU autotools

[Tzafrir Cohen]

On Wed, Jan 12, 2011 at 10:37:34PM +0200, Elazar Leibovich wrote:
> On Wed, Jan 12, 2011 at 4:52 PM, Shachar Shemesh <shachar at shemesh.biz>wrote:
> >
> > fakeroot-ng prefers to use std::unordered_map, if it's available. If not,
> > __fnu_cxx::hash_map would do. If even that's not available, it would
> > grudgingly use std::map, even though that one has worse performance
> > characteristics.
> >
> > The test in its configure.ac is rather largish (not huge, mind you - 50
> > lines including the test for what flags are required to actually make gcc
> > support C++0x), config.h has the following lines (or similar):
> >
> >> /* The type for the map class */
> >> #define MAP_CLASS std::unordered_map
> >>
> >> /* The file to include in order to get the map class */
> >> #define MAP_INCLUDE <unordered_map>
> >>
> >
> >
> This is an excellent example to explain the preferred approach for software
> portability.
> 
> The basic philosophy here is, program to the interface and not to the
> implementation, and the autosuite encourage you to build a fragile ad-hoc
> duck-type-like interface instead of building a robust one.
> 
> What we're lacking here, is an efficient map implementation that conforms to
> the std::map interface. So what I would do in the order of preference in
> this situation is:
> 
> 1) Just use std::map, and ignore the performance penalty, no one will
> probably notice.

People do notice. This does not work in real life (in too many cases).

> 2) Copy an efficient map implementation from somewhere (as in copy-paste),
> eg strinx.sf.net, and use it.

This leads you to having duplicated useless code in your tree.

> 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 how can I pass parameters to the configure script?

(And yes, automake has something for that)

> 
> 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?).
> 
> In the described project, the portability layer (efficient map conforming
> std::map interface) is coupled with the project who uses it (fakeroot-ng),
> and it is not IMHO a desirable design. Even if we can't design around
> autotools, we need to minimize isolate the piece of code which must use it.

This means you'll spend much work on a portability layer. Which you were
trying to avoid. But hey, you don't use autohell.

> 
> Recommending the usage of autotools in every project (and not, say, in
> project whose only goal are to be used as portability layer etc.) encourage
> you to program to the implementation.
> 
> 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
> have anything like pnotify [*] - the autosuite won't really help me. It
> would encourage me to write an ad-hoc half-broken portability layer with m4,
> which is an invitation for troubles. It will certainly won't help me being
> portable. If I must write a portable software which uses diverse API such as
> inotify, and there's no known portability layer, then I should implement my
> own portability layer as a separate project, test it on it's own, and then I
> can be safe and avoid any autotools in my main project.

What you described above is an ad-hoc portability layer written in shell
scripts and Makefiles.


-- 
Tzafrir Cohen         | tzafrir at jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzafrir at cohens.org.il |                    |  best
tzafrir at debian.org    |                    | friend