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.