Changes between Initial Version and Version 1 of CMTInCMake

Timestamp:

Jan 26, 2012, 9:41:50 AM (12 years ago)

Author:

arnault

Comment:

--

CMTInCMake

@@ +1 @@
+= Direct exploitation of requirements by CMake =
+
+== Development environnement 
+
+Code management in SVN is at:
+
+  https://svn.lal.in2p3.fr/projects/CMT2
+
+ * CMake modules are in https://svn.lal.in2p3.fr/projects/CMT2/cmake
+ * Tests environnements are in https://svn.lal.in2p3.fr/projects/CMT2/test
+
+== Principle
+
+We start from a CMake module (CMTLib.cmake) strictly written in CMake language acting as follows:
+
+ * it parses the requirements syntax
+ * it's able to follow the use graph using both the CMTPROJECTPATH (and/or CMTPATH) and the use statements found in the requirements and project.cmt files
+ * then it applies the application or library statements dynamically, generating the add_library add_application statements
+ * it can convert a CMT macro into a CMake variable
+
+The structural convention applied is based on the model that we set up in Atlas: one 'installarea' per 'project'
+
+The result is 100% generic and only refers to requirements files and is meant to be applied to an existing software base structured à-la-CMT.
+
+A simple test sofware base is used:
+ * two projects: one for the test application and one for the libraries
+ * several packages for the libraries
+ * No manual construction of any CMakeLists.txt file.
+ * The build is done within each installarea, the sources are left CMT-based and strictly unchanged
+
+Of course many aspects still need developments and thoughts, among which (the list is not closed):
+
+ * mapping between CMT conventional macros to CMake variables (eg cxxflags ...)
+ * conversion of make fragments into CMake generators
+ * conversion of patterns
+
+== System properties to hold the CMT database:
+ 
+||`CMTPROJECTPATH`||contains the CMTPROJECTPATH env var||
+||`CMTPATH`||contains the CMTPATH env var||
+||`CMT_CURRENT_PROJECT`||contains the current project path||
+||`CMT_PROJECTS`||dictionary of project names||
+||`CMT_USES`||dictionary of package names||
+||`_CMT_<name>_USEPROPERTIES`||context of the macro <name> (gives path & package that defined this macro)||
+||`CMT_MACROS`||dictionary of macro names||
+||`_CMT_<name>`||default value of the macro <name>||
+||`_CMT_<name>_MACROPROPERTIES`||context of the macro <name> (gives path & package that defined this macro)||
+||`_CMT_<name>[<tag>]`||tagged value of the macro <name>||
+
+
+== step 1:
+
+At least, I have been able to apply my simplistic model both on Visual and Unix without any manual action nor any special manual configuration (the CMTLib.cmake module knows nothing to the plateforme)
+
+What I have done is not yet a 'demonstration' that 100% of the CMT concepts can be automatically converted. But at least it demonstrates that one of the main issues that I put focus on, say
+
+ * the use graph management,
+ * the declarative approach
+ * the genericity
+
+can be preserved (perhaps with some editing of the requirements files)
+
+No conceptual showstopper yet.
+
+== step 2
+
+=== new features inCMTLib.cmake:
+
+ * implementing CMT macros:
+   * converted into GLOBAL 'property' 
+   * each macro goes into the "_CMT_<name>" property
+   * or "_CMT_<name>[<tag>]" when a value is associated with a tag
+   * all _CMT_<name> properties are referenced in a dictionary CMT_MACROS (which is itself a GLOBAL property) providing the query functions:
+      * cmt_show_macros
+      * cmt_has_macro
+      * cmt_get_macro_value
+
+ * Some policies are still hard-coded :
+   * all packages install their headers into the installarea of their project
+     * It makes use of the 'configure_file' function
+   * binaries are built in the installarea of the projet
+     * thus, every project declare its installarea as 'link_libraries' location
+   * linking of applications is still driven by the '<app>_linkopts' macro but this macro only contains the library names (since CMake will automatically add the '-l' options)
+
+
+== step 3
+
+ * implement cmt_show_uses
+ * follow trailing \ to parse CMT statements
+
+== step 4 (''to be done'')
+
+ * converting tags
+ * exploiting 'include_dirs' & 'include_path' statements so as to deduce installation of headers into 'installarea'
+ * implementing cmt_show_xxx