On 09/11/2007, daniel g. siegel <[EMAIL PROTECTED]> wrote: > > hello! > > i will begin this mail with a warning: > ************************************** > this topic is highly dangerous, it could result in flame-wars, > holy-wars, suicide, death or murdering. so please be kind and nobody > will get hurt (even not your cat or your hamster) and vincent may gets > an ice cream ;) > ************************************** > > now, as some of you know, cheese uses toc2 as build system. why? will > some of you ask, he could have used autofoo too! well, it wasnt just "i > dont like autofoo and therefore..", the whole decision was made in > several weeks and i really tried autofoo (and got about 7 patches, which > autofoo'd cheese). i want to tell you what kept me off from autotools: > > it always takes three steps > =========================== > most projects in the unix world, who have compiled a package by themself > know that three-step ./configure && make && make install. and in my > opinion i really like it, its simple and gives (at least it should) you > enough options to install it how and where you want. this is fine, but > there are some cases, where this drove me crazy. do i really want to > look through a 1000-lines Makefile and edit my things there, thats just > far to complicate as it really doesnt have any structure. editing > Makefile.in or configure.ac directly? see next point > > exotic? yeah, my holidays are exotic > ==================================== > if you want a build system that works, you would have to know how it > works. so in the case of autofoo i would have to know how m4 works. but > why am i supposed to? i think the discussion about sourcecode management > tools made it clear: we dont want exotic scm-tools, like darcs (which is > coded in haskell), as nobody knows that language. so build systems in > ocaml, lisp, brainfuck, whitespace... hey, the knowledge of a programmer > which is used to c, python, shell, ... should be enough to understand a > build tool. > > im going for a tee > ================== > i think english people can skip that point as they are happy to drink a > tea now and then. its really no problem to wait that really long time > just because you changed a variable name and did a make clean wrongly. > so just enter those three steps and go for a drink somewhere, and when > you come back.... > > cryptology > ========== > yeah, if you are coming back you will find this error message: "ERROR: > haha you will never find out what this error message means". some other > messages are like: "libfoo-1.2.3 found, but you will need at least > libfoo-0.0.1" (this one is really happened to me some weeks ago). i dont > know if the usability experts really want such a thing. > > my grandma used fortran > ======================= > autofoo is checking if i have installed the gnu fortran 77 compiler. of > course it could also check whats the color of my underpants or the > number of illegally aquired songs and movies in my home directory, i > think you get it. > > my hard disk is big enough > ========================== > eog (plain svn checkout): about 40 files for autofoo > eog (after doing a ./configure): about 100 files > this is pretty much, really! even if there are some gigs free on my > harddisk. > > 1010010000010001100 > =================== > /bin/sh ../../libtool --tag=CC --mode=compile gcc [...] `test -f > 'eggmarshalers.c' || echo './'`eggmarshalers.c > > honestly, i never saw a such strange way to compile things... ;) > > toc2 instead > ============ > toc2 instead was really nice, i can edit most of it using bash or > makefiles. its fast as hell and does what i want: > * fast: it doesnt open a shell for each executed command, which > allows to be very fast > * lives in the src-dir > * use whatever language you want to enhance it, in my case bash > and makefiles > * maintaineance is very easy > * custom things: > ./configure --maintainer > enables the maintainer mode, which just sets the paths to the > glade or ui-files correctly, in order to allow an execution in > the src-dir. > make dist > just a normal "make dist", but mine prints the md5sum of the > package so that i just have to copy it > > i made my decision based on that, even though i got _many_ lets say nice > or not so nice messages about that. after about 4 months i am still > satisfied with my decision. > > though my biggest concern about toc2 at the moment is translation > handling, which is not supported by itself and therefore has to be done > manually with xgettext and msgmerge. > > so richard hughes and ali sabil told me about waf > (http://code.google.com/p/waf/) as a build system replace for toc2, > which would support translations nicely. has anyone used this tool? > > > > please understand, i dont want to bring up a "autotools is bad and it > should die"-thread, i just want to use my time to code and not to use > that time and effort on a build system. i also know, that i have stabbed > into a beehive, so please be kind lets keep this discussion objective > and realistic. > > > thanks a lot for reading the whole mail till here and not pressing the > "reply flame"-button immidiately ;)
I have several problems with autotools in addition to the ones mentioned by Daniel - to all of which I concur completely. * Autotools writes obfuscated output. You cannot possibly determine what's going on. Ant gets this a tad better and cmake makes acceptable output (even with a % progress) * Hard to debug. Debug messages are cryptic and buried within tons of useless output * Hard to get things "right". I've already spend a considerable amount of time trying to get Autotools to do what I intend. I remember my first encounter with Ant at work. It took me a day to be comfortable and productive. Autotools still scares the shit out of me. * Drives novice hackers away because of the above reasons >From my personal perspective my first project where I completely had to build up my autotools setup from scratch (xesam-glib) I've spend roughly the same time getting all the autotools-foo working (with gtk-doc generation and passing make distcheck etc etc) as i did hacking on the actual code. That is just so immensely frustrating and I would have stopped hacking on it was it not for my relentless passion to bring search bliss to the Gnome world. It is important to realize that GObjects impose an extra level of abstraction on top of the usual OO-programming people learn because you basically have to implement both Class and Instance code. I claim that 95% of all Java/.Net/Python hackers are used to implementing only the Instance part (or atleast this is how they think of it). The aspiring Gnome hackers have a very steep learning curve just for the GObject system. Adding Autotools on top makes Gnome very inaccessible. I know because I am a rookie myself. Please don't say that new comers can hack in Python or other bindings because we really need people with C programming skills. Consider the GTK+ teams recent callout for additional devs. Many projects find them selves in a similar position. Peace. Cheers, Mikkel PS: I am completely aware that it is unrealistic to replace autotools in Gnome 2. For Gnome 3 let's kill it.
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
