[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CMake [was:Re: Successfully merged projects]
From: |
Søren Hauberg |
Subject: |
CMake [was:Re: Successfully merged projects] |
Date: |
Mon, 11 Apr 2011 19:10:04 +0200 |
man, 11 04 2011 kl. 11:08 -0400, skrev John W. Eaton:
> On 11-Apr-2011, John Swensen wrote:
>
> | I think we can incorporate qmake into the regular Octave autotools, but
> qmake definitely makes some things easier. For example, qmake already
> handles making MOC files and dealing with making an app bundle for OSX
> platforms. This encompasses a lot of rigamarole if attempted through
> autotools (I think). The point is that we would have to figure out how to do
> a bunch of stuff the "autotools way". Is there something wrong with having
> an autotools target that calls
> | 1) qmake in the UI directory
> | 2) make in the UI directory
> | We already need QT to even build the thing and qmake is distributed with
> QT, so it isn't as if we are adding another dependency.
>
> I would like to avoid a recursive invocation of Make. It is
> preferable to have the top-level Makefile know everything about how
> the project is built. That way all the dependencies can be specified
> more precisely. I would also prefer to avoid mixing CMake and/or
> qmake into the build process.
In the last couple of years I have worked on a project where I have been
forced to use CMake. It has the advantage that it improves things for
Windows and OS X developers, but honestly I find that it is a huge step
backwards on Linux. Random bullet points:
* It's really annoying that I have to install CMake in order to
build stuff from a tar-ball. With autotools all I need
is /bin/sh.
* Installing things in a non-standard location is far less obvious
than with autotools. In the latter case you write ./configure
--prefix=/opt/stuff while with CMake you have to write make
-DCMAKE_INSTALL_PREFIX=/opt/stuff (Imagine how many hours it
took me to chase down that little piece of information...).
* Documentation is crap. It is hard to imagine a project with
worse documentation than autotools, but CMake so much worse that
it is almost fascinating.
* In general you have to write a bunch of "Find" modules every
time you want to use an external library. It seems like CMake
was designed with a focus on monolithic projects rather than
modular ones.
* The CMake syntax is just as obscure as the one in the autotools,
so it rarely makes things easier.
All in all, I've found CMake to be a step forward for Windows and Mac
developers, but a rather large step backwards for Linux developers. I
tend to be rather agnostic when it comes to choice of tools, but I have
found so little to like about CMake, that I think it's fair to say that
I actually dislike it.
Anyway, enough ranting for today :-)
Søren
- Re: Successfully merged projects, (continued)
- Re: Successfully merged projects, Richard Crozier, 2011/04/11
- Re: Successfully merged projects, Richard Crozier, 2011/04/11
- Re: Successfully merged projects, John Swensen, 2011/04/11
- Re: Successfully merged projects, Richard Crozier, 2011/04/11
- Re: Successfully merged projects, John W. Eaton, 2011/04/11
- Re: Successfully merged projects, John W. Eaton, 2011/04/11
- Message not available
- Fwd: Successfully merged projects, Jacob Dawid, 2011/04/11
- CMake [was:Re: Successfully merged projects],
Søren Hauberg <=
- Re: CMake [was:Re: Successfully merged projects], Jordi Gutiérrez Hermoso, 2011/04/11
- Re: CMake [was:Re: Successfully merged projects], Søren Hauberg, 2011/04/11
- Re: Successfully merged projects, Michael Goffioul, 2011/04/11
- Re: Successfully merged projects, John Swensen, 2011/04/11
- Re: Successfully merged projects, Jacob Dawid, 2011/04/11
- Re: Successfully merged projects, Michael Goffioul, 2011/04/11
- Re: Successfully merged projects, Jacob Dawid, 2011/04/11
- Re: Successfully merged projects, Jacob Dawid, 2011/04/11
- Message not available
- Re: Successfully merged projects, Jacob Dawid, 2011/04/11
- Re: Successfully merged projects, Michael Goffioul, 2011/04/11