[Gecode] Subversion
Guido Tack
tack at ps.uni-sb.de
Wed Aug 17 17:54:43 CEST 2005
> However, as good as subversion might be, what is still highest on my list
> of software infrastructure is a reasonable set of Makefiles.
I've made some experiments with the Makefiles. I have tried the
automake/libtool-based system, and a handmade Makefile that basically does
the same as Makefile.win, but for Linux.
On my machine, the automake-based complete build (using make check, including
all examples) takes 6:21 minutes, 6:19 if I switch off dependency tracking.
With the handwritten Makefile, building everything takes 5:55 minutes. That's
26 seconds or 7% more using automake. Let's have a look at the advantages and
disadvantages of automake:
+ it knows how to build shared and static libs on at least Linux and MacOS
+ it knows where to install stuff on different platforms
+ it supports building in a separate directory
+ it makes packaging easy
+ dynamic dependency tracking
- it clutters the command line
- it is slower
- it requires a lot of stuff in the configure script that seems useless (check
for f77 ;)
- when building the examples and linking against shared libs, libtool creates
wrapper shell scripts -> bad for using gdb
- it is horribly slow on Cygwin/Windows
- it does not work at all with the Microsoft compiler
Some other problems that are however solvable:
* it does not provide targets for generating assembly files (fixed by
additional handwritten rules)
* we have one Makefile.am per module, so no Makefile knows all files, which
makes generating the documentation a little harder (can be solved by putting
everything into one Makefile.am)
Actually, I was a bit surprised that automake is not that much slower. I think
there's a high windchill factor involved when you change something in the
kernel, you have to recompile everything, and it just takes ages... With the
handwritten Makefiles, you at least see what's going on - the output of the
dependency tracking stuff makes everything /look/ even slower.
I do not really know how well automake's dependency tracker works. I did not
have the impression that too much gets recompiled, though. It only adds 2
seconds to the build time, and it is dynamic - you don't have to call "make
depend" if you changed anything. Of course it would be possible to replace it
with a "classic" depend target. Then the output looks much cleaner (you can
try it by using --disable-dependency-tracking as a configure option).
To sum up: the biggest problem for us seems to be that we have to maintain two
Makefiles: one for Windows, and one for the rest of the world. I don't think
speed is that critical - if it is, we can still use handwritten makefiles for
development and automake for deployment. I will try to write a configure.ac
and toplevel Makefile.am that work for both g++ and msvc, so that we only
have to maintain one list of sources/targets. Maybe that will even allow us
to use handwritten Makefiles for development and automake for deployment
(although I don't see so many advantages of that scheme any more).
Maybe I forgot some (dis)advantages, so I'd be interested in your opinion
about automake/libtool.
Guido
--
Guido Tack
Programming Systems Lab, Saarland University, Saarbrücken
http://www.ps.uni-sb.de/~tack
More information about the gecode-users
mailing list