schulte at imit.kth.se
Wed Aug 17 22:58:30 CEST 2005
Frankly, I care fuck about how you do things.
However, for the last, one important thing is to have makefiles that suppot
the development of Gecode (please be selfish). Automake sucks big time here
(remember: fucking around with LD_LIBRARY_PATH, installing librraies
somwhere, etc). Secondly, just because of automake we have two makefiles
anyway. That's it. Forget autoamke. It is the biggest timesink I have ever
seen in my life. If you don't remove it, I'll do.
From: gecode-bounces at ps.uni-sb.de [mailto:gecode-bounces at ps.uni-sb.de] On
Behalf Of Guido Tack
Sent: Wednesday, August 17, 2005 5:55 PM
To: Technical discussions about Gecode
Subject: Re: [Gecode] Subversion
> 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,
all examples) takes 6:21 minutes, 6:19 if I switch off dependency tracking.
With the handwritten Makefile, building everything takes 5:55 minutes.
26 seconds or 7% more using automake. Let's have a look at the advantages
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
for f77 ;)
- when building the examples and linking against shared libs, libtool
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
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
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
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
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
Programming Systems Lab, Saarland University, Saarbrücken
Gecode mailing list
Gecode at ps.uni-sb.de http://www.ps.uni-sb.de/mailman/listinfo/gecode
More information about the gecode-users