[flashrom] [PATCH] Autodetect target processor architecture

[Carl-Daniel Hailfinger]

Am 30.06.2011 21:03 schrieb Peter Lemenkov:
> 2011/6/30 Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at 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

-- 
http://www.hailfinger.org/