Am Dienstag, 11. Dezember 2007 19:40 schrieb Derek Atkins:
> Christian Stimming <[EMAIL PROTECTED]> 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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
