r18717 - gnucash/trunk/src - Add some experimental CMakeLists.txt which can compile the libqof part, on Linux, Windows/mingw and (no joke) Windows/MSVC.
jralls at ceridwen.us
Wed Feb 24 22:46:37 EST 2010
On Feb 24, 2010, at 10:18 AM, Geert Janssens wrote:
> On Wednesday 24 February 2010, Christian Stimming wrote:
>> Author: cstim
>> Date: 2010-02-24 12:52:24 -0500 (Wed, 24 Feb 2010)
>> New Revision: 18717
>> Trac: http://svn.gnucash.org/trac/changeset/18717
>> Add some experimental CMakeLists.txt which can compile the libqof part, on
>> Linux, Windows/mingw and (no joke) Windows/MSVC.
>> I'm interested in some tests with the cmake build system, but
>> if it doesn't prove useful I will remove it again within a
>> few weeks.
>> gnucash-patches mailing list
>> gnucash-patches at gnucash.org
> Great idea!
> The issue we had on Windows the last couple of days had me thinking about a
> univeral build system we could use on all our supported platforms. Cmake may
> be a good candidate, I thought of as well.
> I don't have any experience with cmake though, so at this stage I won't be of
> much help.
> But I wanted to let you know I'm interested anyway :)
I recommend Bakefile (http://www.bakefile.org), which has the major advantage of preparing build scripts for the native build tools without introducing a dependency for people compiling from tarballs. CMake is its own build tool.
That said, neither CMake nor Bakefile will solve the M$Win problem, because there's just no way to maintain cmakelists or bakefiles for the several dozen dependencies (jhbuild counts them, so I know that it takes 76 packages to build Gnucash from scratch -- and that
doesn't include autotools or perl. Actually, if someone with some M$Win & Python skills were interested, I think jhbuild would prove much more maintainable that the current collection of shell scripts. That's still not going to get you MSVC projects, though; jhbuild is very autotools-centric.)
More information about the gnucash-devel