Die GNU autotools

[Elazar Leibovich]

On Thu, Jan 13, 2011 at 12:03 AM, Tzafrir Cohen <tzafrir at cohens.org.il>wrote:

> > 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).
>

I really think that in most cases CPU is not the bottleneck, but of course
it can be false for a specific application. This is not the main point here.


>
> > 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.
>

Again, from a purity POV this is bad, since you could add this duplicated
code as a library and it would be more sound. However from practical POV,
it'll work, it's reduce dependencies of the project, it makes it more
portable, and it's good enough.


>
> > 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?
>

You don't. That's the whole point. In 99.9% of the cases, you don't want to
pass parameters to the configure script. A portable efficient std::map
implementation is an example where you should design your program so that no
parameters would be needed. the autosuite will figure out which platform are
you in, and will compile the appropriate files for this platform. But your
main logic wouldn't need the autosuite at all, the main logic of your code
would only depend on the portability layer.


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

I'm not sure I follow you here:
1) I'm not sure why moving the platform dependent code to a small separate
project will make you waste more time on it, than building it inside your
main project.
2) I tried to make clear that when writing a portability layer it makes
sense to use the autosuite in order to figure out where you are, so I'm not
sure I follow your last (cynical?) comment involving the term "autohell".


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

Again, I'm still not sure I follow you. I didn't recommend using shell
scripts and makefiles in order to write the portability layer, the autosuite
makes perfect sense there. My point it, it shouldn't appear in any other
code than the portability layer, where the autotools configuration is a part
of the logic.
(Indeed, if you don't have something like pnotify, you have to write it (or
at least part of it) yourself for your portable inotify project, but this is
true regardless of your usage of the autosuite).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110113/e261bdcd/attachment-0001.html>