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