[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