current state of using cmake to compile kdevelop
neundorf at kde.org
Mon May 9 18:40:09 UTC 2005
On Sunday 08 May 2005 23:58, Sylvain Joyeux wrote:
> > Yes, I heard this.
> > But which are exactly the portability issues ?
> libtool takes care mostly of PIC/non-PIC issues,
Which issues ? Creating shared libs is trivial with cmake under linux, mac os
X and windows (didn't try other platforms).
> linkpath and rpath,
cmake takes care of them (AFAICT).
> dynamicly-loadable modules, ...
Hmm, what's to do there ?
> One thing I like is that it builds *both* version of the libraries (shared
> an non-shared), which lets the developer choose which one he wants to use
> *without* changing its build system.
What is this good for ?
cmake can do the same too if you want it to.
> it also does library versioning and (tries to) take care of the
> dependencies. Libtool tries to put the dependent libraries on the linker
> command line in an order which works. It fails sometimes, but still it is
> better than nothing
cmake also supports all these features AFAICT.
> BTW, out of curiosity, why cmake and not (for instance) scons ?
The question is slightly wrong.
From my POV we have exactly two alternatives to autohell: scons and cmake. I
had a look at scons some time ago, and it felt strange. I have to write a
program to compile my software.
With cmake I specify how I want my program to be compiled.
And cmake can create native project files for: GNU make, MSVC, Apple XCode,
KDevelop and others. I'm using cmake since maybe 2 years now, on linux, mac
os X, windows and for cross-compiling and I am very satisfied with it.
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org - http://www.kde.org
alex at neundorf.net - http://www.neundorf.net
More information about the KDevelop-devel