current state of using cmake to compile kdevelop

[Alexander Neundorf]

Hi,

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.


Bye
Alex
-- 
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