| Re: [cdt-dev] Future of Managed Build |
|
I've not had chance to catch up on the whole e-mail thread yet so this might have already been covered. A while ago I made a start on a new managed build system that due to other work commitments I've not yet had chance to start sharing. I was designing that system so the toolchain & project configuration mechanisms were completely separate from the actual build file generation/build engine. Any logic needed to determine how to rebuild on changes was going to be placed
in a build engine specific implementation, so if targeting a tool like Ninja which can handle those cases itself there would be no special handling inside the managed build system, it would just be generating the Ninja files. The idea with that to keep the
core managed build system as small as possible to make it possible connect with different build tools without running into conflicts with how they handle things. Quick overview of the system I'd started. I’ve got the basics of the configuration files both for build settings & the toolchain definitions working but didn’t yet connect a build fine generator yet. 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 (XText DSL) containing only the options data, not structural information about the toolchain
·
Configuration selection though launchbar, select configurations rather than projects.
Regards William -----Original Message----- > On 1 Feb 2020, at 18:54, Liviu Ionescu <ilg@xxxxxxxxxx> wrote: > > ... project configuration. What I poorly tried to explain is that this is a complex subject; some tools (like cMake) try to combine it with the builder; other tools may choose to split some functionality to a separate tool. The configuration step may include one-time pre-build operations (like auto-detecting system capabilities, or choosing one of multiple cross tools for different architectures), but also application options, that can be changed at any
moment during the project life time (like thread stack sizes, queue sizes, etc). Changing some of these options are reflected only in the content of some header files included in the build, and the builder should be perfectly able to handle the dependencies, but some changes may be reflected in different files being
added to/removed from the build, for example when building a portable project for different platforms/architectures. To be noted that the pre-build system capabilities auto-detecting step (introduced by autotools, and took to the extreme by cMake) is not a mandatory step. The other choice is the npm/xPack philosophy: instead of detecting the existing
capabilities and trying to make the best use of them by 'bending' the project after them, it is easier to compose the project from mandatory packages (executables and sources) and have a dependency mechanism bring into the project exactly the needed versions. --- These are generally tricky issues, and the exact demarcation line between tools is hard to draw. In brief, a build system must acknowledge that project configuration should be addressed somehow, either internally or externally. Regards, Liviu _______________________________________________ cdt-dev mailing list To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647 |