[Gecode] Subversion

[Christian Schulte]

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.

CS

-----Original Message-----
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,
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

_______________________________________________
Gecode mailing list
Gecode at ps.uni-sb.de http://www.ps.uni-sb.de/mailman/listinfo/gecode