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 [email protected] |----------------------------------------- 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. _______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
