Zitat von John Ralls <jra...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
