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
+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.
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.