| Re: [cdt-dev] Managed Core Build |
|
+1. Right now Core Build already assumes one toolchain per build configuration so that should work. Yes, feel free to raise bugs and we can have detail discussions there on the various topics. Doug. From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of William Riley I went for making configurations the launch object at the moment as it seemed the simplest and least invasive way to get something working. Executables would make sense if the mode selector could work well for configuration
selection. Definitely something that needs to be discussed, with a view to improving the launch bar if needed. Regarding toolchains, at the moments my thoughts are to keep managed build simple and stick to supporting 1 toolchain per ‘configuration’. With multiple configurations per project automatic configuration selection based
on toolchain could still be added, though I think it would need some form of mapping UI as users could have more than 1 applicable configuration. I’ve got a rough solution for supporting persistent configurations via CBuildConfigurationManager, involving pushing the configurations into CBuildConfigurationManager when the provider initializes, but I’m not particularly
happy with it. Another discussion to be had here. Should I start opening Bugzilla bugs to track things like this? Regards William From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer +1 Great plan William. I especially like the use of an editor for the options. This would make it similar to CMake, Meson, etc. and maybe encourage GUI editor for those systems too.
☺. We’ll need to see how the launch bar goes. Right now, it selects build configurations based on the selectors, and the mode in particular. The middle descriptor selector isn’t really meant to be projects, it should be things that launch,
i.e. executables mainly, but other things. An idea I’ve bounced around is to make the mode selector extensible and allow it to be the build configuration selector, which it kinda does now. We are certainly open to enhance the model there. Good point about the toolchain versus the editor. Might be a hole in our thinking. Have to think about that a bit more. Thanks! Doug. From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of William Riley 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.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
|