On 26/11/2015 17:53, Svante Signell wrote:
On Thu, 2015-11-26 at 17:04 +0000, Roger Leigh wrote:
On 26/11/2015 15:00, Svante Signell wrote:
On Thu, 2015-11-26 at 15:33 +0100, aitor_czr wrote:
Hi, what's wrong with plain GNU make, and the GNU auto-tools?
Nothing is wrong with "plain make", providing that it meets your needs.
But often you want more than plain make can offer. There's plenty to
criticise with the autotools, the baroque complexity being the primary
one. CMake is a big upgrade from the autotools; it's vastly more
featureful and powerful, has better portability for modern systems, and
still works with make when generating Makefiles. The autotools have
failed to keep up to date with modern portability requirements; the
capabilities CMake has to offer are unmatched at the present time,
though it also has its own warts. After 15 years of autotools use, I
converted all my stuff to CMake over the last two years, and I'm not
looking back.
Then you are a happy user of cmake. I'm working on porting packages for GNU/Hurd
and every time when I encounter packages using cmake the confusion increases. It
seems almost impossible to find out where to make changes and, the build process
is not traceable. (maybe It's just me :( )
You looked at CMakeFiles/CMake(Output|Error) ? Most stuff should be
logged there. And if you need to trace, message(WARNING) will print a
trace along with the diagnostic.
I do think there is a lot of confusion about CMake. But I don't think
this is due to any intrinsic fault of the tool, it's more due to a
general lack of familiarity with how it works (and why) since it's newer
than the autotools, which we're all familar with. I remember how
confused I was by the autotools back in the late '90s. After spending
days reading about all of the internals (autoconf, m4, make, automake,
libtool), I finally got how it all fit together and was really pleased
when I got my first project working with the autotools. But that
success took a *significant* investment of time and effort, and I
continued to use and contribute to these tools for several projects over
the next 15 years, primarily out of inertia and because they were "good
enough" once you'd got past all the complexity.
A couple of years back, starting a new C++ project at work, I had to
decide on a build system to satisfy all our requirements. The autotools
would have been a candidate were it not for also needing to build on
Windows, so I took a fresh look at everything out there, including
scons, cmake and several others. CMake was the best of the lot. As for
the autotools, I spent several days learning it. I took an existing
autotooled project (schroot) which used a lot of autoconf/automake
features including custom stuff, and converted it to use cmake over the
course of a week. After that investment of effort, I was 90% there in
terms of understanding it.
For anyone at home with m4/autoconf/automake/libtool, there's a great
deal of similarity with cmake. The main difference is that it's vastly
simpler--instead of having several tools, each using a different
language and its own set of configuration files and macros, you have one
language and one file (which can include others). Other than that, most
of the concepts (feature testing, defining targets) are exactly what you
already know, just done slightly differently. When working in a team,
it's much better since they can make changes without being gurus, and
*everything* is in the manual--it's much easier to get into than the
autotools.
Regards,
Roger
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
