d***@duaneellis.com
2018-05-01 20:50:58 UTC
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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers