[cmake-developers] new generator question - xml file output for embedded IDE platforms.

[duane at duaneellis.com]

Hi - 

I'm looking into adding a new "generator" type, that is basically a
fancy form of "configure_file()"

At this point, I've been stepping through Cmake code trying to
understand the general flow
and want to ask the question: Is this insane or stupid? Or not a bad
idea.

Some details to understand where I am headed and what I'm thinking.

Generally, cmake produces a makefile, or - for example with Visual
Studio it produces an XML file directly.

In my case, I am focusing on micro-controller *embedded* targets - and I
need to produce various XML files that are required by IDEs.
In other cases I need to create GNU makefiles for command line gcc-arm
it varies.

I also need the ability to create Visual Studio (or linux) projects
because it is often very helpful to create unit tests for libraries that
can run on a host platform for some embedded libraries - it is this unit
test part that makes Cmake is an interesting solution.

For the EMBEDDED target - some assumptions & major compromises for this
type of target is important and must be made - ie: You cannot compile
and execute something, many of the various tests and such will just not
be possible.  The IDEs often cannot really manage re-running Cmake  -
(basically some IDEs perform an IMPORT operation)

To simplify - I want to limit the supported items to two things: 
     Build (1 to N) static libraries.
     Build & Link (1 to N) applications, typically this produces an ELF
file
     Optionally extract a HEX or BIN file from the ELF file.

The IDEs generally have:
   A top level Workspace file - Much like a Visual Studio SLN file.
   Each project has its own file - much like visual studio.
   There are sometimes additional files to be created
   Something for the debugger, or perhaps a "config.h" type file

The goal here is not just compiling the code but fully supporting the
IDE experience, ie: all debugger features work better if you build using
the IDE

My hunch is this:
     What is really needed is a TEMPLATE language - and to some degree
that is what I am proposing and want feed back on.

Assume the following is present, ie: on the command line or via a
CMakeLists.txt file in a subdirectory
    A variable with the TOOL NAME (with version number)
    A variable with the CHIP NAME

Then - 
    Based on the TOOL & CHIP NAME - I can find (and read) other files
with more details.
    For example Endian, specific ARCH ie: ARM CortexM3 vrs Atmel AVR
    Chip specific information like:  Size of FLASH, starting address of
FLASH, RAM, etc.

    AND - a directory that contains lots of "template" files

Here are some example project files that might be generated.

ARM - Kiel uVision -
   
https://github.com/ARM-software/CMSIS_5/tree/develop/CMSIS/DSP/Projects/GCC
   Specific examples:
   
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/DSP/Projects/GCC/arm_cortexM_math.uvoptx
        Source files appear around line 3000 ... there are many of
these.

IAR project
   
https://github.com/ARM-software/CMSIS_5/tree/develop/CMSIS/DSP/Projects/IAR
    the EWW file - is the Workspace, the EWP is the PROJECT

   IAR also has something called an "argvars" file- used to set
variables used across projects within a workspace.
   Example:  
       
https://github.com/ti-simplelink/ble-sdk-210-extra/blob/master/Projects/ble/multi_role/CC26xx/IAR/multi_role.custom_argvars

   IAR also has "icf" files - yet another xml file.
   Key point: This file is "imported" by the IDE in a *one*way* import
step.

TI  CCS - supports something called a PROJECT SPEC file
    Narrowly focusing on the ARM targets TI has their own compiler, plus
they support the GCC compiler)
    While the TI-CCS is an ARM-eclipse environment - they do support
eclipse project files
    But that has its own list of issues when we talk about cross
compiler tools.

    http://processors.wiki.ti.com/index.php/ProjectSpecs_in_CCS

   
https://github.com/ti-simplelink/ble_examples/blob/master/examples/rtos/CC2640R2_LAUNCHXL/bleapps/peripheral_bidirectional_audio/tirtos/ccs/peripheral_bidirectional_audio_cc2640r2lp_app.projectspec

If I narrow the supported list of features to something generally like
this:

For a given target:

a) In some cases, might need to produce a "top level workspace file"
(more below)
   Might need to add a standardized variable, ie:
CMAKE_IDE_WORKSPACE_NAME or something.

b) For a target - given a list of source files - create one or more
static libraries.
  - CMake has this basic input construct already

c) given a list of source files - create an 'executable' - that may link
against the above libraries (plus others that are pre-built)
  - Cmake has this basic construct now.

d) Some common things, ie: A list of Include Directories, a list of
command line defines
  - Cmake has this

e) The ability to GENERATE something like  "foobar.h" from the file
"foobar.h.in"
  - Cmake has this, with some limited supported features

f) The ability to copy a file from (a template) directory into the
"build" directory
   An example might be the startup assembly language file.
  - Cmake has this, via the configure_file() command.

f) What's missing is the XML file creation - 
   I want to really avoid writing a *CUSTOM* xml creator for each tool
and each chip
   The permutations are horrible.

Only SOME of the Cmake commands would be used/required/supported, for
example
(below is an invented XML syntax that shows the types of things that
might be needed)

 <xml>

 @if( ${FEATURE} )@
    <feature-foo-enabled-enable value="true">
 @else()@
    <feature-foo-enabled-enable value="false">
 @endif()@

 <another-method value="@${FEATURE}@">  

 @foreach( SOURCEFILE ${SOURCE_FILE_LIST} )@
    <source> @${SOURCE_FILE}@ </source>
 @endforeach()@

 <linker-lib-search-dir>
     @foreach( this_library ${TARGET_LIBRARY_LIST} )@
         @library( GET_LIBDIR this_dirname ${this_library} )@
         -L@{this_dirname}@
     @endforeach()@
 </linker-lib-search-dir>

 <linker-libnames>
     @foreach( this_library ${TARGET_LIBRARY_LIST} )@
         @library( GET_LIBNAME this_libname ${this_library} )@
         -l@{this_libname}@
     @endforeach()@
 </linker-lib-search-dir>

 </xml>

=============

I think - the above would cover about 80 to 90% of the use cases.

Am I insane? and architecturally Cmake is not the way to do this?


Thanks.