adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] CMake


From: Kai Sterker
Subject: [Adonthell-devel] CMake
Date: Fri, 6 Feb 2009 21:34:48 +0100

Nearing the release of 0.4 alpha 3, I turned my attention to the build stuff.

One issue to date has been that the CMake based build didn't generate
the adonthell.pc file for pkg-config, which is required to build the
tools. I changed that today. It's not perfect, as the file will always
be installed under $prefix/lib/pkgconfig, meaning that it could end up
in a place where pkg-config will not look by default. However, one can
always set the PKG_CONFIG_PATH and things will be fine.


Then there is another issue that didn't bother me much so far (as I
mostly use the automake build), but that came up again recently when
Frederico did a couple of builds. If you have the adonthell libs
installed, CMake would link to the installed libs instead of the ones
created in the build tree. Which either caused the build to fail when
there had been interface changes or caused glitches when classes had
gained extra members and things would no longer line up.

For latter, some testing showed that it is a problem of CMake 2.4.x
only, which generates linker invocations like the one below:

Linking CXX executable worldtest
cd /Users/kai/adonthell/adonthell-cmake/test && /usr/local/bin/cmake
-P CMakeFiles/worldtest.dir/cmake_clean_target.cmake
cd /Users/kai/adonthell/adonthell-cmake/test && /usr/bin/c++
-fno-strict-aliasing -fno-strict-aliasing -headerpad_max_install_names
-fPIC "CMakeFiles/worldtest.dir/worldtest.o"   -o worldtest
-L/Users/kai/adonthell/adonthell-cmake/src/base
-L/Users/kai/adonthell/adonthell-cmake/src/gfx
-L/Users/kai/adonthell/adonthell-cmake/src/input
-L/Users/kai/adonthell/adonthell-cmake/src/main
-L/Users/kai/adonthell/adonthell-cmake/src/world
-L/Users/kai/adonthell/adonthell-cmake/src/audio
-L/Users/kai/adonthell/adonthell-cmake/src/event
-L/Users/kai/adonthell/adonthell-cmake/src/python
-L/Users/kai/adonthell/adonthell-cmake/src/py-wrappers/runtime -lltdl
-ladonthell_base -ladonthell_gfx -ladonthell_input -ladonthell_main
-ladonthell_world -ldl -ladonthell_audio -ladonthell_input
-ladonthell_gfx -ladonthell_event -ladonthell_python -ladonthell_base
-L/usr/local/lib -lxml2 -lltdl -lz -ladonthell_py_runtime -framework
Python -L/usr/local/lib -lpng12

OTOH, CMake 2.6.x creates the following invocation:

Linking CXX executable worldtest
cd /Users/kai/adonthell/adonthell-cmake/test && /usr/local/bin/cmake
-E cmake_link_script CMakeFiles/worldtest.dir/link.txt --verbose=1
/usr/bin/c++     -fno-strict-aliasing -fno-strict-aliasing
-fno-strict-aliasing -Wl,-search_paths_first
-headerpad_max_install_names -fPIC
CMakeFiles/worldtest.dir/worldtest.o  -o worldtest  -lltdl
../src/base/libadonthell_base.dylib ../src/gfx/libadonthell_gfx.dylib
../src/input/libadonthell_input.dylib
../src/main/libadonthell_main.dylib
../src/world/libadonthell_world.dylib -ldl
../src/input/libadonthell_input.dylib
../src/audio/libadonthell_audio.dylib
../src/gfx/libadonthell_gfx.dylib
../src/event/libadonthell_event.dylib
../src/python/libadonthell_python.dylib
../src/base/libadonthell_base.dylib -L/usr/local/lib -lxml2 -lltdl
/usr/lib/libz.dylib
../src/py-wrappers/runtime/libadonthell_py_runtime.dylib
-L/usr/local/lib -lpng12 -framework Python

So I would assume that this issue should no longer come up with the
newer versions of CMake. Question is, is it a big enough issue to
force the use of CMake 2.6 or later? I just updated anyway, so it
wouldn't matter to me :-). Some distros might still ship old versions,
however. I at least wouldn't install a new build tool just to try out
some little demo game ...


Then there's the thing about packaging. With the autotools build I can
run 'make dist' and get a tarball of the source at least. CMake comes
with the cpack tool that can build a multitude of packages, but not
without some extra instructions. Anyone willing to look into that, so
that we can at least do a 'make dist' from the cmake build as well?
Creating additional binary packages would be a nice bonus.


And finally, the tools don't have a cmake build at all. For sake of
consistency, we should probably offer the same build system for the
tools as for the engine. Again, anyone willing to have a look at this?

Kai




reply via email to

[Prev in Thread] Current Thread [Next in Thread]