Am 28.08.2015 um 15:20 schrieb Michael Schlenker:
Am 28.08.2015 um 01:53 schrieb Noel Butler:
That's why I want us to extend cmake to do the unix build as well.
The biggest bitch I here from *nix/bsd system admins everywhere is
cmake, the largest bitch is people know how to use --with-foo --with-bar
now after decades, THEY, the people you expect to use your software,
have to learn it no longer works that way, I know of multinationals
change software because of cmake, I've seen a well known large
international issue a policy that they will remain on old unsupported
versions of mysql because they moved to cmake.
autoconf et al, might be ol school, but every man, woman, and dog knows
and understands it,
Knows yes. Understands autoconf/m4/libtool in depth: Highly in doubt
about that claim, the vast amount of cargo culted libtool/m4/configure
macros floating around speaks against it.
Autoconf/libtool is great when it works. But if it does not, you are in
for a world of pain.
CMake is different yes, and has quite a few warts of its own, but it is
vastly simpler to understand and reason about than libtool/configure/etc.
Regarding cmake as a solution to get rid of those dsp/dsw files:
YES!
Cmake provided project/nmake/make files have one issue though, which
might not be obvious to someone never using cmake: Those depend on cmake
for a variety of tasks (e.g. install tasks are often done by invoking
some 'cmake -E' stuff and so on, via extra build tasks).
I want to strengthen this point: IMHO very similar to configure, using
cmake as a generator without having cmake on the system where you run
the build likely will not work. You can't just run it at release time,
generate nmake or vcxproj files and the consumer only uses MSVC to do
the build. The end user will need to run cmake on his system. I have
seen cmake calls in the generated nmake files, but also full absolute
paths to extracted source files etc. in the generated vcxproj files. So
those can't be generated at release time.
I'm not terribly experienced with cmake though and maybe it has a more
friendly generation mode.
Despite those problems, I don't know of a better way to maintain the
build artefacts we need to ensure windows platform support.
So if one killed off the dsp/dsw files, it gets harder to adjust and
tweak the created projects in VisualStudio, you need to fix the CMake
file and recreate the project file. Which isn't that much different to
the way autoconf works with configure.in etc.
CMake does a few things nicer than libtool/autoconf, especially when you
are NOT a linux distro builder. For example it doesn't force you to use
-rpath everywhere like libtool does, can create installers/rpms etc. out
of the box and has various other conveniences.
But to make it really good, there should be some standard FindAPR.cmake
file provided (and sent to kitware for inclusion), to make it easier for
packages using apr to detect the bits, pieces and parts.
Rainer
