<div dir="ltr"><div class="gmail_quote">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).</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">But what I'm saying is,</div><div class="gmail_quote">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).</div>
<div class="gmail_quote">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.</div>
<div class="gmail_quote">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.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">As a result I conclude, that if your project goal is not to provide a portability layer, it should not use the autosuite.</div><div class="gmail_quote"><br></div>
<div class="gmail_quote">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)).</div>
<div class="gmail_quote">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.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Jan 12, 2011 at 11:38 PM, Nadav Har'El <span dir="ltr"><<a href="mailto:nyh@math.technion.ac.il">nyh@math.technion.ac.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Wed, Jan 12, 2011, Elazar Leibovich wrote about "Re: Die GNU autotools":<br>
<div class="im">> 3) Have a project in a separate directory which implements an efficient map<br>
> in a siusing existing map implementation. For this project, it makes sense<br>
> to use autotools. But this project will provide a solid testable interface<br>
> (ie .hpp file) for this map.<br>
<br>
</div>So basically, you're proposing that one big project with a complex autoconf<br>
setup is split into many different subprojects (libraries), each with its<br>
own autoconf setup? This suggestion may be valid in certain cases, but<br>
you're still ending up using autoconf - perhaps even more of it...<br>
<br>
At the end, some piece of code needs to check, at build time, whether the<br>
system's compiler and libraries already include a map implementation, or<br>
they don't. Autoconf (and its heirs to the throne, mentioned by others on<br>
this thread) does this pretty well.<br>
<div class="im"><br>
> This way, my main project have a straightforward build system, and the<br>
> portability layer is isolated from the project, testable and more portable<br>
> (what if we'll have a platform with buggy std::map implementation we can't<br>
> use? In case of (3) we can easily borrow one, and change the portability<br>
> layer only. What would the ng-fakeroot project do for such a system?).<br>
<br>
</div>What do you do if you have a realtively small project (not something like<br>
OpenOffice) and you find yourself with 7 different "portability layers"<br>
for all sorts of small features like this - do you really prefer having<br>
7 different libraries, 7 build systems, 7 different "separate projects",<br>
and so on, compared to what Shachar described - simple #ifdefs that solve the<br>
problem?<br>
<div class="im"><br>
> What about the case of inotify/Linux fragmented audio system, etc, etc.?<br>
> Again, the autosuite won't save the day here. If I want to write a portable<br>
> program which uses inotify (which is kind of oxymoron, as inotify is a Linux<br>
> specific API), what I really want is to program to a layer of abstraction<br>
> above inotify, which is portable to as many system as possible. If I don't<br>
<br>
</div>You're basically saying the same thing I am, but reaching a different<br>
conclusion. Indeed, a portable program can't rely on inotify because that<br>
is only available on Linux, and only certain versions thereof. When inotify<br>
is not available, it needs to resort to other mechanisms which might be<br>
available, and when all else fails, resort to slow-and-ugly polling.<br>
Certainly, and sensible program design will wrap all these options into one<br>
function or library inside this project, and use this function throughout<br>
the projects. Still, when compiling this function, somebody needs to choose<br>
whether to compile inotify code, or one of the other options - and this<br>
somebody is autoconf (or one of its competitors). If you compile this<br>
function-or-library separately, basically nothing changes - you still need<br>
to make decisions at compile time.<br>
<div class="im"><br>
> would encourage me to write an ad-hoc half-broken portability layer with m4,<br>
<br>
</div>Unless you need to invent completely new kinds of tests - and in 99% of the<br>
cases you don't - you don't actually need to learn m4 to use autoconf.<br>
I do agree that m4 is ugly and was an unfortunate choice.<br>
<br>
<br>
--<br>
Nadav Har'El | Thursday, Jan 13 2011, 8 Shevat 5771<br>
<div class="im"><a href="mailto:nyh@math.technion.ac.il">nyh@math.technion.ac.il</a> |-----------------------------------------<br>
</div>Phone +972-523-790466, ICQ 13349191 |Love doesn't make the world go round -<br>
<a href="http://nadav.harel.org.il" target="_blank">http://nadav.harel.org.il</a> |love is what makes the ride worthwhile.<br>
</blockquote></div><br></div>