Die GNU autotools

[Elazar Leibovich]

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

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.

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