Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
too bad cmake and scons continue to re-solve the same problems autotools solved eons ago
(cross-compiling / tool discovery / custom flags). scons in particular is just terrible and
not in any sort of usable shape for serious projects.
LCA: Disintermediating distributions
Posted Feb 7, 2008 1:33 UTC (Thu) by modernjazz (guest, #4185)
So why are so many projects, which already have "working" autoconf build
systems, doing all that "useless work" to switch to CMake? The next thing
that happens is most of them seem to express great satisfaction and
relief with the result. Is this just self-delusion to justify the work?
Posted Feb 7, 2008 10:25 UTC (Thu) by drag (subscriber, #31333)
Like the migration lots of projects have done from going from CVS to SVN to Git or whatever
When mucking around with a program have you ever noticed that once you program something out,
but find some reason to rewrite it, that it turns out to be better then your original version?
Ya sure you could of spent that time bugfixing the old code or hacking new features into it,
but your going to be almost certain that the new code is going to make your job of maintaining
and improving it just that much better.
I have a feeling that if many of those projects just stripped out all the stuff they used make
(or autotools or whatever) for and then reimplimented it from scratch then they would of been
nearly as happy with it.
Also projects that are ho-hum about converting to cmake are not all of a sudden going to turn
around and broadcast to the world that they spent a great deal of their time on something that
ended up not mattering a whole lot. It's not like they are going to end up being examples
while other projects just love it.
Posted Feb 7, 2008 10:59 UTC (Thu) by modernjazz (guest, #4185)
Sure, a simple project works great with any of several build strategies,
so of course not everyone will be thrilled by switching. But if CMake
only lacks the "I got burned by #!@%*& CMake" contingent, it's already
ahead of the competition.
Posted Feb 7, 2008 12:36 UTC (Thu) by nix (subscriber, #2304)
My *eyes* got burned by cmake's language.
Haven't they learned that capital letters make things *harder* to read? Have we learned
nothing since the days when Lisp was written in capitals?
Posted Feb 7, 2008 14:26 UTC (Thu) by aleXXX (subscriber, #2742)
Since CMake 2.4.3, released July 2006 (or around that version) the
commands can be written lowercase, with the coming version 2.6 this is
even the preferred style (i.e. which is used in the documentation).
Posted Feb 7, 2008 21:28 UTC (Thu) by nix (subscriber, #2304)
YES! (Time to upgrade. Is my cmake really that old?
... 2.4.1. dammit.)
Posted Feb 7, 2008 22:10 UTC (Thu) by aleXXX (subscriber, #2742)
2.4.1 was a beta version, a lots of bugs were fixed for 2.4.3. Version
2.4.8 has been released a few weeks ago, I recommend you use this. If
there is no package for your distro, just download the binary package
from www.cmake.org and just unpack it in some place you like, it will
Posted Feb 7, 2008 23:19 UTC (Thu) by nix (subscriber, #2304)
Yeah, like I said, it was really stupid of me not to upgrade. In fact I've
*got* a more recent version installed: it's just this bloody old version
in /usr/local/bin was hiding it... *sigh* chkdupexe time, I think.
Posted Feb 7, 2008 20:24 UTC (Thu) by vapier (subscriber, #15768)
i didnt say it wasnt working *for them*. they probably wouldnt have made the build system
change if it wasnt working *for them*. the trouble is when *anyone else* tries to build the
package. you want to cross-compile it ? build it on a different platform ? build with your
own compiler/flags ? sorry, but the $flavor-of-the-month build system never thought of that.
time to go re-implement the wheel even though autotools already had it solved.
Posted Feb 7, 2008 21:47 UTC (Thu) by nix (subscriber, #2304)
The worst I've found for this is Boost.Jam. It should *not* take 7Kb of
diffs and a kilobyte of build-system shell scripting to do the equivalent
of setting --prefix and CXXFLAGS when building Boost!
Posted Feb 7, 2008 22:17 UTC (Thu) by aleXXX (subscriber, #2742)
I'm not sure I get your point here, so I just state what cmake offers
CMake cvs (2.6.0 will be released soon) supports cross compiling (without
scratchbox or any other emulators, but of course it can also be used
If you want to use your own CFLAGS/CXXFLAGS with CMake, you have at least
two ways to do it:
set CFLAGS/CXXFLAGS when you run cmake, cmake will use them.
Or, later on, run "make edit_cache" and edit the
CMAKE_C_FLAGS/CMAKE_CXX_FLAGS directly to what you want.
If you build the software on some system where it has never been built
before it may very well be necessary that you have to do something on the
buildsystem, add some more checks, add some other locations, other names
for libraries (e.g. z lib has a lot of different names on Windows). I
guess this is true for any buildsystem.
Posted Feb 7, 2008 22:40 UTC (Thu) by vapier (subscriber, #15768)
your comment backs up my point. all of these alternative build systems consistently re-solve
the exact same problems that autotools solved eons ago.
cmake *just* added support for cross-compiling (and it isnt even in any released version) ?
without even looking at anything else about cmake, that tells me the project is useless to me.
i'm not saying my needs are the same as everyone out there, just that you cant champion a
replacement for autotools if it isnt a replacement. i'm glad *you've* found it useful, but if
your target compiling audience is more than just you, then i feel sorry for those poor chaps
(where chaps != you).
the things i cite are just common examples ive come across quite frequently when dealing with
non-autotooled packages as a distribution maintainer (whether it be cmake or scons or hand
rolled or whatever). they certainly a complete list. i imagine there are numerous other
portability fixes autotools has which these "replacements" lack.
Posted Feb 7, 2008 23:22 UTC (Thu) by nix (subscriber, #2304)
autoconf-generated configure scripts also support the godsends which are
site-config files. Nobody else seems to remember about that, which means
you need to wrap another build system around your build system just to get
your CFLAGS et al consistent.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds