= 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