Changes between Version 19 and Version 20 of developpements


Ignore:
Timestamp:
Jan 26, 2012, 9:42:37 AM (12 years ago)
Author:
arnault
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • developpements

    v19 v20  
    11= Developments at LAL
    2 
    3 == Direct exploitation of requirements by CMake ==
    4 
    5 === Development environnement
    6 
    7 Code management in SVN is at:
    8 
    9   https://svn.lal.in2p3.fr/projects/CMT2
    10 
    11  * CMake modules are in https://svn.lal.in2p3.fr/projects/CMT2/cmake
    12  * Tests environnements are in https://svn.lal.in2p3.fr/projects/CMT2/test
    13 
    14 === Principle
    15 
    16 We start from a CMake module (CMTLib.cmake) strictly written in CMake language acting as follows:
    17 
    18  * it parses the requirements syntax
    19  * 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
    20  * then it applies the application or library statements dynamically, generating the add_library add_application statements
    21  * it can convert a CMT macro into a CMake variable
    22 
    23 The structural convention applied is based on the model that we set up in Atlas: one 'installarea' per 'project'
    24 
    25 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.
    26 
    27 A simple test sofware base is used:
    28  * two projects: one for the test application and one for the libraries
    29  * several packages for the libraries
    30  * No manual construction of any CMakeLists.txt file.
    31  * The build is done within each installarea, the sources are left CMT-based and strictly unchanged
    32 
    33 Of course many aspects still need developments and thoughts, among which (the list is not closed):
    34 
    35  * mapping between CMT conventional macros to CMake variables (eg cxxflags ...)
    36  * conversion of make fragments into CMake generators
    37  * conversion of patterns
    38 
    39 === System properties to hold the CMT database:
    40  
    41 ||`CMTPROJECTPATH`||contains the CMTPROJECTPATH env var||
    42 ||`CMTPATH`||contains the CMTPATH env var||
    43 ||`CMT_CURRENT_PROJECT`||contains the current project path||
    44 ||`CMT_PROJECTS`||dictionary of project names||
    45 ||`CMT_USES`||dictionary of package names||
    46 ||`_CMT_<name>_USEPROPERTIES`||context of the macro <name> (gives path & package that defined this macro)||
    47 ||`CMT_MACROS`||dictionary of macro names||
    48 ||`_CMT_<name>`||default value of the macro <name>||
    49 ||`_CMT_<name>_MACROPROPERTIES`||context of the macro <name> (gives path & package that defined this macro)||
    50 ||`_CMT_<name>[<tag>]`||tagged value of the macro <name>||
    51 
    52 
    53 === step 1:
    54 
    55 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)
    56 
    57 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
    58 
    59  * the use graph management,
    60  * the declarative approach
    61  * the genericity
    62 
    63 can be preserved (perhaps with some editing of the requirements files)
    64 
    65 No conceptual showstopper yet.
    66 
    67 === step 2
    68 
    69 ==== new features inCMTLib.cmake:
    70 
    71  * implementing CMT macros:
    72    * converted into GLOBAL 'property'
    73    * each macro goes into the "_CMT_<name>" property
    74    * or "_CMT_<name>[<tag>]" when a value is associated with a tag
    75    * all _CMT_<name> properties are referenced in a dictionary CMT_MACROS (which is itself a GLOBAL property) providing the query functions:
    76       * cmt_show_macros
    77       * cmt_has_macro
    78       * cmt_get_macro_value
    79 
    80  * Some policies are still hard-coded :
    81    * all packages install their headers into the installarea of their project
    82      * It makes use of the 'configure_file' function
    83    * binaries are built in the installarea of the projet
    84      * thus, every project declare its installarea as 'link_libraries' location
    85    * 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)
    86 
    87 
    88 === step 3
    89 
    90  * implement cmt_show_uses
    91  * follow trailing \ to parse CMT statements
    92 
    93 === step 4 (''to be done'')
    94 
    95  * converting tags
    96  * exploiting 'include_dirs' & 'include_path' statements so as to deduce installation of headers into 'installarea'
    97  * implementing cmt_show_xxx
    98 
    99 
    100 == Others Dévelopments
    1012
    1023 * [wiki:Sébastien Sébastien]