potentially using cmake (was: Re: r16624 - gnucash/trunk - Remove the spurious m4/ directory.)

[Christian Stimming]

Am Dienstag, 11. Dezember 2007 19:40 schrieb Derek Atkins:
> Christian Stimming <stimming at tuhh.de> writes:
> > The whole point of cmake is that it will perform all those
> > platform-checks (more precisely: host and target checks) which used to be
> > done by the autoconf-generated shell scripts which nobody was able to
> > understand. But the price for this is that cmake is required to be
> > installed on the host.
>
> What do you mean by "nobody was able to understand"?  The configure
> script is mostly Shell script with a bunch of m4 convenience macros to
> implement pieces of shell script over and over.

configure.in is a shell script, yes. But that shell syntax, if it should be 
portable enough, IMHO counts as "difficult to understand" - it's easy for 
*us* only because all of us have been using and writing shell scripts for 
decades by now.

The mixup of configure.in as shell script and the m4 macros parsed by m4 also 
counts as "difficult to understand". Quoting rules of m4 interspersed with 
quoting rules of the shell were, well, challenging. The argument passing of 
m4 also counts as "difficult to understand".

I'm not going to prove on system is giantically better or easier than the 
other. Build systems are complex because the task is complex. My point here 
about cmake is that after working with it in several non-trivial projects, I 
think it has some advantages which will pay off in the long run, where 
particularly the autotools will continue to have problems for a long time to 
come. The learning curve for newcomers is one of them.

> > Yes, it will make libtool completely go away. Relief! :-)
>
> I suppose making libtool go away might be good.  But I find
> that libtool seems to get the job done.

Well, now after the year of work on getting the windows port done, your last 
statement is true. However, all that extra tweaking that autotools needed for 
getting the windows port right (on mingw+gcc) would have been way easier with 
cmake, because this use case is built right into cmake from the beginning.

> Is cmake going to make the build system faster?  Easier to
> understand?  Easier to maintain?  Is there really a problem
> with the current build system that we're trying to fix and
> cmake can fix it?
>
> What's the motivation for migrating?

Curiosity.

Really, there isn't any hard reason for gnucash *right now* to consider an 
immediate switchover from the autotools build system to cmake. *But* in the 
long run we might want to support yet more platforms and/or compilers, and 
*if* we want to do that, it might be worth to do this with cmake instead of 
autotools because most probably it will be way easier there. ("Extreme" 
example: Building gnucash with Microsoft MSVC compiler. If anyone wanted to 
do this, with cmake it would come almost for free, whereas with autotools it 
is impossible.)

And just of out personal motivation (to learn something new), cmake is a 
worthwhile excercise to get used to. It will be used in more and more 
projects in the future.

Other than that, yes, cmake is much faster than autotools. cmake 
replaces ./autogen.sh and ./configure by the single "cmake" call, but make 
and make install are extra calls. My estimate for the "cmake" step for a 
project of the size of gnucash is approx. 10 seconds at the first time 
(compared to the approx. 60-120 seconds right now) and 1-2 seconds on 
subsequent rebuilds (compared to 30-60 seconds right now). And yes, it is 
easier to understand and easier to maintain. Of course not if you count in 
your decade-long autotools experience, but in a fair comparison, newcomers 
would find cmake much more easier to understand and easier to maitain.

Whatever. As I said, my mention of cmake is mostly because of personal 
curiosity, and some long-term advantages it would give. But it's nothing that 
becomes important for gnucash in the short run.

Christian