Buildsystem TODO list

[Alexander Neundorf]

Hi all,

if you have some time to contribute to the buildsystem, below is a list of 
things which need to be done short term, i.e. in the next months, mostly for 
KDE frameworks.

--------------------------------------------------------
Take care of Strigi, Nepomuk & Soprano buildsystem-wise
--------------------------------------------------------

Allen wrote last week to kde-buildsystem that there are multiple 
FindSoprano.cmake files, they differ and they need work.
I would add that personally I'm still somewhat confused by Strigi, Nepomuk, 
Soprano, Raptor, Virtuoso and friends, and since they all belong somehow 
together, it would be nice if somebody would volunteer to take care of the 
cmake stuff for them.
This means:
- take care of the Find-modules
- the projects themselves (Strigi, Nepomuk, Soprano) should install 
Config.cmake files to help with finding them
- keep an eye on which of those packages are optional to kdelibs/parts of KDE 
frameworks and make that work properly


--------------------------------------------------------
Upstreaming stuff into CMake
--------------------------------------------------------

We are quite good with that:
http://community.kde.org/index.php?title=KDE_Core/Platform_11/Buildsystem/FindFilesSurvey
CMake 2.8.6 will make most of our custom macros obsolete, and also most of our 
duplicated find-modules in kdelibs have been merged.
There are still some macros from kdelibs left, where we still need to find out 
how to proceed:

* MacroBoolTo01.cmake is used a lot. But is it actually still necessary ?
Where and how is it used ?
Would using #cmakedefine01 (instead of #cmakedefine) in the to be configured 
files (e.g. config.h.in) make this unnecessary ? (see the documentation for 
configure_file on the cmake manpage)

* CheckStructMember.cmake: 
This differes from CheckStructHasMember.cmake (which comes with cmake) in that 
it uses a C++ compiler for the test instead of the C compiler.
It would be a good idea to find all uses of check_struct_member() in KDE SC, 
and put them into a standalone CMakeLists.txt.
Then we can check for each one whether the CheckStructHasMember.cmake gives 
the same result.
If so, we don't need this file for KDE frameworks anymore.
If such a C++ version is indeed needed, then I'll add a 
CheckCXXStructMember.cmake to CMake for the 2.8.7 release.

* CheckPointerMember.cmake
same as above. It would be nice to put all test(s) from KDE SC which use 
check_pointer_member into a standalone CMakeLists.txt, and then check whether 
the same could be done using CheckStructHasMember.cmake, coming with cmake.
If this is possible, CheckPointerMember.cmake can be removed for KDE 
frameworks. If not, we should add something like this to cmake for the 2.8.7 
release.

* CheckPrototypeExists.cmake
Where is this used ?  Who is 1d0e1a0 ? Can the same be tested e.g. with 
check_symbol_exists() ?


And there is one bigger, actually coding task:

* CheckCXXSourceCompiles.cmake, CheckCXXSourceRuns.cmake
These are identical to the ones coming with CMake, but additionally they 
support using imported targets in CMAKE_REQUIRED_LIBRARIES.
We should create a cmake feature branch which integrates this into cmake, but 
not only for these two files, but I guess for all macros coming with cmake 
which use the CMAKE_REQUIRED_LIBRARIES variable (i.e. grep for it in Modules/ 
).
If done nicely, this branch can be merged into cmake, and we'll have it in 
2.8.7.


---------------------------------------------
Putting Find-modules into extra-cmake-modules
---------------------------------------------

Each of the Find-modules in extra-cmake-modules/attic/modules/ needs to be 
reviewed before it can be moved to the proper location in e-c-m.
This means it must follow the following rules:
http://techbase.kde.org/Policies/CMake_Coding_Style
http://www.cmake.org/cgi-
bin/viewcvs.cgi/Modules/readme.txt?root=CMake&view=markup

So, if you decide to work on some of those files, please put your name behind 
the file here in the wiki: 
http://community.kde.org/index.php?title=KDE_Core/Platform_11/Buildsystem/FindFilesSurvey

It is also possible that some of our Find-modules in kdelibs are not used 
anymore, but could not be removed due to source compatibility.
Are there such files ?


----------------------------------------------------------
Handling different CMake versions with extra-cmake-modules
----------------------------------------------------------

This needs some real thinking.
When we ship and install e-c-m, this will be a whole bunch of find-modules and 
some macros.
Some macros will be unique to e-c-m, some will be extended versions of macros 
shipped with cmake, e.g. CheckCXXSourceCompiles.cmake.
A user of e-c-m will probably set the CMAKE_MODULE_PATH so that the files from 
e-c-m are found.
Should the files which extend/duplicate stuff from CMake be in a separate 
directory so the using project can decide whether it wants everything from e-
c-m or or only the files which are not in CMake ?
But, e.g. FindSQlite.cmake is currently not in CMake, so it would now be an 
add-on. But later on it may be added to CMake, then the version in e-c-m would 
be an override.
How do we deal with that ?
Or should we support projects which want to define in detail which files from 
e-c-m they want to use ? E.g. with a macro like
ecm_use_modules(FILES CheckCXXSourceRuns FindSQLite MacroBoolTo01
                DIRECTORY ${CMAKE_BINARY_DIR}/cmake)
This could copy the listed files from the e-c-m directory into the build tree 
of the project, and then the project would *only* get those files it 
explicitely listed from e-c-m. OTOH the using project would have to make sure 
it copies this way all needed files into its buildtree (e.g. 
CheckCXXSourceRuns.cmake uses 
HandleImportedTargetsInCMakeRequiredLibraries.cmake internally).

Or could something be done with some logic in each of the files ?
Something like e.g. for a FindFoo.cmake in e-c-m:
if(${CMAKE_VERSION} VERSION_GREATER 2.10.0)
  include(${CMAKE_ROOT}/Modules/FindFoo.cmake)
  return()
endif()

I.e. explicitely forwarding to the original cmake version if cmake is newer 
than some specific version ?
Or should we somehow organize all the files into cmake-version specific 
subdirectories ? (I'm not sure how this could work...)


Whereever you produce results, please post them either to the buildsystem list 
or put them in the techbase or community wiki (and post links to the 
buildsystem list).

Thanks
Alex