r18717 - gnucash/trunk/src - Add some experimental CMakeLists.txt

[Christian Stimming]

Zitat von John Ralls <jralls at ceridwen.us>:
>> 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,

Currently the cmake experiments are just that - experiments. But I  
should mention the reasons for my choice, which is simple: At my  
daytime job, I have been using cmake in several projects for years  
now. Those projects are required to compile on Linux/gcc,  
Windows/mingw and (guess what) Windows/MSVC, and they have plenty of  
dependencies are well. So I thought I would try to apply my experience  
here, and that's how I ended up in the cmake experiments.

Off-topic: Why I think cmake is better than autotools:

The statement "cmake is its own build tool" is not correct - the  
actual build will be done by Makefiles (on Linux and Windows/mingw,  
the "generators" in cmake terminology; MSVC is different). However,  
cmake for sure solves the build-managment problem on a different level  
of abstraction than the autotools: Autotools claim that the dependency  
checking at build time could be done with only a shell (via  
./configure), which will generate the required makefiles for the  
actual build. CMake, on the other hand, claims that dependency  
checking needs cmake, which will generate the required makefiles for  
the actual build. After all the years, I think the cmake approach is  
better, because of one single reason: In the autotools approach, the  
knowledge of all different (supported) build hosts has to exist in the  
autotools itself, and additionally in the generated ./configure. So it  
is duplicated always. In cmake, the knowledge about the supported  
build hosts is in cmake, and that's it. No duplication of the build  
knowledge from the autotools side to some obscure shell scripting  
code. The downside, of course, is that cmake will always be required  
if the package is built from source. On the other hand, when building  
the package from source, you always have dozens of requirements, so  
the addition of this one doesn't harm particularly bad. (badly?)

My biggest perceived benefit here (German: "die wichtigste gefühlte  
Verbesserung", almost untranslatable) is that re-generating the  
Makefiles takes 1 second. Really. If it's slow, it might take 1.5  
seconds. Hence, changes in the CMakeLists.txt will cause at most 1.5  
seconds of penalty. Compare this to a change in configure.in and the  
resulting waiting time. Coffee drinking time.  Yawn. Next coffee  
cooking time. Coffee dish washing-up time. Yawn. Coffee dish tidy up  
time. Newspaper reading time. Yawn. And even some more time, until all  
the autotools stuff has eventually finished checking the host system...

End off-topic.

The speed-up in host system checking is my main reason for this  
experiment. The MSVC support is just a funny add-on, for now.

Regards,

Christian