| [cdt-dev] Managed Core Build |
|
Hi As discussed on a previous CDT call I have started looking at replacement for managed build, built on Core build. Rather than trying to adapt the current managed build system to core build this will
be a new implementation. My current plan is to work on this system to exist in parallel with the current managed build system until we are sure it is stable and mature enough to fully replace the current managed build. I
am going to be working on getting a prototype version ready in the next couple of months. I have created the following list of high level requirements the new system will satisfy. These are based on internal usage within Renesas, the GCC implementation in CDT, and the issues we have with
the current system. This list is not complete and feedback from the community is needed here as I know Renesas's use cases don’t cover everyone. High level requirements:
·
GUI to allow configuration of build options for a project
o
Options for both "Tools" & "Toolchains"
o
String, Enum, Boolean & list types supported
o
Allow overriding of GUI by toolchain implementers
·
Support multiple "configurations" for each project using the same or different toolchains
·
UI should allow multiple configurations to be opened at the same time to allow users to compare configurations
·
Support for multiple build systems (planned to support Ninja & make)
·
A settings file which can be safely stored in version control & be easily merged with standard merge tools (unlike the current .cproject where the structure can change without any build
options actually being changed)
·
Users should be able to add custom tools to an existing toolchain within an individual configuration
·
Mechanism for contributing toolchain converters, which could convert the build options from one toolchain to another. Current working ideas:
·
Make the options UI an editor rather than a property page, accessible either using real files or virtual nodes in the project explorer
·
Configuration setting file (deciding between either XML or JSON) should contain only the options data, not structural information about the toolchain
·
Configuration selection though launchbar, select configurations rather than projects.
Current issues: Currently core build assumes the target selection can change the toolchain, however in order to be able to provide a full options UI the toolchain needs to be known ahead of time. I haven't get worked
out how to resolve this conflict yet. There are a few solutions I am considering but I am currently just working on implementing with a single fixed toolchain per configuration. Regards William
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. |