[CMake] cmake integration

[Pavel Volkovitskiy]

Eric Noulard wrote:
> 2007/2/9, Pavel Volkovitskiy <int at mtx.ru>:
>> >
>> Looks like cmake's developers doesn't plan world domination? :)
>> Or may be it's not possible to use generic rules to run cmake's based
>> make-system?
>
> What do you mean by "generic rule" ?
> An exemple would be welcomed.
>
sorry for my english, i'll try to explain
i don't want to build a program with cmake
instead i want to add cmake support for conary
(distributed software management system, http://wiki.rpath.com/wiki/Conary)
in other words - not build conary with cmake,
but build with conary other applications which uses cmake buildsystem

now conary has good support for configure based buildsystem
for example in foo.recipe (file which tells conary how to build foo from 
source)
===============================================
class Foo(AutoPackageRecipe):
   name = 'foo'
   version = '1.2.3'
   def unpack(r):
      r.addArchive('http://foo.org/files/')
   def configure(r):
      r.Configure('--enable-kde')
===============================================
that's enough for conary to run configure, make and make install and 
make binary package of foo
in this example (on x86_64) conary will run:
===================================
cd /home/int/conary/builds/foo/foo-1.2.3/; \
CLASSPATH="" CFLAGS="-O2 -g" CXXFLAGS="-O2 -g " CPPFLAGS="" LDFLAGS="-g" 
CC=gcc CXX=g++  \
./configure \
   --prefix=/usr \
   --exec-prefix=/usr \
   --bindir=/usr/bin \
   --sbindir=/usr/sbin \
   --sysconfdir=/etc \
   --datadir=/usr/share \
   --includedir=/usr/include \
   --libdir=/usr/lib64 \
   --libexecdir=/usr/libexec \
   --localstatedir=/var \
   --sharedstatedir=/usr/com \
   --mandir=/usr/share/man \
   --infodir=/usr/share/info \
   --enable-kde
===================================
almost every configure script uses this flags and parameters, so foo 
will install libraries under /usr/lib64,
mans under /usr/share/man (and in most cases it will use C(XX)FLAGS 
which was specified)

i named this "generic rule"
you don't need to look how you should specify libdir: '--libdir, 
--lib-dir, '--dir-for-lib', etc', it's always named '--lib-dir'

so if i want to make a distro with x86 and x86_64 packages i set "lib" 
macros to "lib64" on x86_64 platform
(x86 packages will use /usr/lib and x86_64 packages will use /usr/lib64)

and if i want to build a pure 64bit distro i set "lib" macros to "lib" 
and both 32bit and 64bit packages will uses /usr/lib

now with cmake:
It seems the only thing i can always add is CMAKE_INSTALL_PREFIX, there 
is no other standart variables for paths
so one app will install plugins under /usr/lib/foo/, another will use 
/usr/lib64/bla/
one app will use /usr/man/ for man pages and another will use 
/usr/share/man, etc

so i tried to find useful variables which will work for most packages 
which is uses cmake:
===================================
CC=gcc CXX=g++  cmake \
   -DCMAKE_C_FLAGS:STRING="-O2 -g" \
   -DCMAKE_CXX_FLAGS:STRING="-O2 -g " \
   -DCMAKE_EXE_LINKER_FLAGS:STRING="-g" \
   -DCMAKE_MODULE_LINKER_FLAGS:STRING="-g" \
   -DCMAKE_SHARED_LINKER_FLAGS:STRING="-g" \
   -DCMAKE_INSTALL_PREFIX:PATH="/usr" \
   -DUSE_KDE=YES \
   /home/int/conary/builds/foo/foo-1.2.3/
===================================
looks like all cmake based buildsystems should use these variables, am i 
right?
if something otheres useful variables, which i may add, exist?

And it seems there is no equivalent for "--libdir" or other standart 
configure parameters?

All i want is to make it possible to replace
r.Configure('--enable-kde') with r.CMake('-DUSE_KDE=YES')

>>
>> I have another question too...
>> conary has ability to autodiscover build reqs for auto* make-system
>>
>> so i want to implement same feature for cmake's make-system
>> Now i'm looking for requirements in CMakeCache.txt
>> (search lines like ASPELL_LIBRARIES:FILEPATH=/usr/lib64/libaspell.so)
>>
>> but some CMakeLists.txt uses something like this:
>> """
>> IF(ASPELL_FOUND AND NOT USE_KDE3)
>> ...
>> ELSE(ASPELL_FOUND AND NOT USE_KDE3)
>>   IF(USE_KDE3)
>>     MESSAGE(STATUS "Spell plugin is disabled when building with KDE")
>> """
>> ie checks for aspell in any case, so if we cooking package with kde 
>> support
>> we will have autodiscovered build requirement which is not really 
>> needed.
>
> What do you mean you check for ASPELL_FOUND even if you
> don't need to use ASPELL?
>
> Your CMakeLists.txt does not show the part where ASPELL is "discovered"
> may be with something like
> FindPackage(ASPELL).
>
>> Is this may be checked somehow? if any way exist to dump only really
>> used variables?
>
> I don't get your point. Dump where? In CMakeCache.txt?
>
>> Or maybe this CMakeList just bad written?
>
> Send the whole CMakeLists.txt and add comment where appropriate
> I think it would be easier for us to understand what you want.
>

It's not my CMakeList.txt, i use sim-im as example of program with cmake 
based buildsystem
CMakeList.txt (from sim-im sources) always checks for ASPELL but doesn't 
uses it if USE_KDE=TRUE

I want to know if this common practice (find everything even if you 
don't need it) or if this CMakeList.txt has bugs
(ie it shouldn't check for aspell if it's not going to be used)

Now about buildrequrements auto-discover.
after conary build binary package with configure script it looks in 
config.log to discover build requrements of package
(ie if configure scripts checks for libaspell.so -> aspell should be 
added as build requirements for this package)

with cmake based build system i guess CMakeCache.txt is equivalent for 
config.log
so now conary builds package
(ie cmake; make; make install)
and then looks in CMakeCache.txt and if it found 
"ASPELL_LIBRARIES:FILEPATH=/usr/lib64/libaspell.so"
it adds aspell as build requirement for package

the problem is that sim-im always tries to find aspell library even if 
it will not use it during build

so i wonder if there is better way exist to auto-discover real build 
requirements of package


-- 
Pavel