Direct exploitation of requirements by CMake

Development environnement

Code management in SVN is at:


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:

CMTPATHcontains the CMTPATH env var
CMT_CURRENT_PROJECTcontains the current project path
CMT_PROJECTSdictionary of project names
CMT_USESdictionary of package names
_CMT_<name>_USEPROPERTIEScontext of the macro <name> (gives path & package that defined this macro)
CMT_MACROSdictionary of macro names
_CMT_<name>default value of the macro <name>
_CMT_<name>_MACROPROPERTIEScontext 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
Last modified 12 years ago Last modified on Jan 26, 2012, 9:41:50 AM