Am 30.06.2011 21:03 schrieb Peter Lemenkov:
2011/6/30 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
Using autoconf would imply at least a fourfold increase in compile time,
Does anybody cares? Ok, anyway, we don't need to guess - let's count:
work ~/work/flashrom (git::fedora-next): time autoreconf -if
real 0m3.911s user 0m2.231s sys 0m0.244s work ~/work/flashrom (git::fedora-next):
This would be run very occasionally, so I wouldn't bother about autoreconf invocation - just for the record. Running ./configure is more frequent operation but it also requires only when we change something in configure.ac and Makefile.am:
As a maintainer, I compile pretty much every patch I submit or review in at least two different configurations. That differs from the usual user experience, though.
work ~/work/flashrom (git::fedora-next): time ./configure 2>&1 > /dev/null
real 0m5.572s user 0m2.202s sys 0m1.674s work ~/work/flashrom (git::fedora-next):
And now, the most frequent (but not the last) operation:
work ~/work/flashrom (git::fedora-next): time make 2>&1 > /dev/null
real 0m4.922s user 0m4.072s sys 0m0.927s work ~/work/flashrom (git::fedora-next):
Wow, that machine is really fast! flashrom compilation takes roughly 30 seconds on my machine.
Finally, let's install the resulting binary:
work ~/work/flashrom (git::fedora-next): time make install DESTDIR=/var/tmp/flashrom-autotools 2>&1 > /dev/null
real 0m0.160s user 0m0.091s sys 0m0.054s work ~/work/flashrom (git::fedora-next):
Now, let's compare with the current buildsystem. Firstly, we will run "configure + make" target:
work ~/work/flashrom (git::master): time make 2>&1 > /dev/null
real 0m5.385s user 0m4.282s sys 0m1.157s work ~/work/flashrom (git::master):
I'd say it two times faster (assuming that we'll run ./configure every time we using autotools - and we won't). And lets try to install:
work ~/work/flashrom (git::master): time make install DESTDIR=/var/tmp/flashrom-custem 2>&1 > /dev/null
real 0m0.494s user 0m0.295s sys 0m0.188s work ~/work/flashrom (git::master):
Still (in)significantly fast but anyway - three times slower :).
To even consider autotools at all, two basic requirements must be met:
- Zero compile time increase (that includes the configure step in a
pristine tree).
- Total lines of code to be maintained do not increase either.
Yes. LOC number is significatly lower in case of autotools and handmade Makefile:
sulaco ~/work/flashrom (git::fedora-next): LANG=C wc -l configure.ac Makefile.am && wc -l Makefile 241 configure.ac 186 Makefile.am 427 total 523 Makefile sulaco ~/work/flashrom (git::fedora-next):
Now that is interesting. Do you have a git tree or a patch set somewhere so I can take a look?
And there are some cleanups in the sources as well which I didn't count.
I am interested in those as well.
So I can answer with confidence - the number of LOCs will be less than now and the compile time will be almost the same (difference in 5 seconds).
The CMake-based buildsystem however has one major drawback - it requires cmake to be installed (aototools requires themselves only for reconfiguration). And keeping in mind that different major CMake versions have major incompatibilities I'd rather say that it's better not to use it at all - it adds more issues than fixes them. I can say it for sure because I've got very interesting experience of maintaining compatibility of CMake-based buildsystem for relatively large project among three major CMake branches - 2.4, 2.6 and 2.8.
Hm. My past autotools experience was really abysmal regarding compatibility between autotools versions, so I doubt CMake can be worse. The idea behind autotools is good, but the implementation was garbage 7 years ago despite claims to the contrary. Having been burned back then, I'm very reluctant to consider autotools for anything.
Nowadays most of the changes in the Makefile are either additions for new programmers or fixups for new gcc/clang versions. Autotools won't affect the former, but I have no idea if it could prevent the latter. It would be nice, though.
That said, your makefile/configure file sizes look impressive and I'd really like to check how they handle all the conditional feature enabling we have now. Maybe autotools are really more mature now and I should throw my doubts away.
Regards, Carl-Daniel