diff --git a/CMake/TODO b/CMake/TODO index 5e52f494cfdbab36cd06d4d02be7fb9912b2abe1..44bb7c9cb7a2c988be0ec7609102c82de2af134f 100644 --- a/CMake/TODO +++ b/CMake/TODO @@ -13,6 +13,16 @@ * Python package are not yet part of the CMake build. +* In order for SubSystem build to succeed, it is necessary that meta-packages + can be used as a real target -- so that you can "make LCS" to build all LCS + packages -- much like the lofarconf.in file do in the Autotools environment. + Specifying the packages as dependencies using lofar_add_package() will + not work, because then these packages cannot be optional. Maybe we should + change the semantics of lofar_add_package() to something that is now + handled by lofar_add_subdirectory(); and have a new macro, e.g. + set_package_dependencies(), that can be used to define the actual package + dependencies. + * Define ${PROJECT_NAME}_LINK_LIBRARIES in LofarAddPackage.cmake, which can then be used by lofar_add_library() and lofar_add_executable() in LofarMacros.cmake. This avoids the need to create a "dummy" project library, @@ -46,13 +56,3 @@ * Turn makeversion into a real CMake macro and merge it with LofarPackageVersion. Generate the Package__Version.{h,cc} files in the binary directory, instead of the source directory. - -* It would be nice if a meta-package could be used as a real target -- so that - you could for example say "make LCS" to build all LCS packages -- much like - the lofarconf.in file do in the Autotools environment. - Specifying the packages as dependencies using lofar_add_package() will - not work, because then these packages cannot be optional. Maybe we should - change the semantics of lofar_add_package() to something that is now - handled by lofar_add_subdirectory(); and have a new macro, e.g. - set_package_dependencies(), that can be used to define the actual package - dependencies.