Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Future of Managed Build

Hi All,
I support the idea to try to use the modeling frameworks for the management project build. On my life experience in the IDE and Tool productization, the modeling part at a first look is a little bit complex. But as a result, using EMF and Xtext approach allow experts to focus on Project codebase details, instead of "where" and "how" I should it define. In other words, I expect from the "modeling", decrease time on development and maintenance and at the same time some clear and flexible way of definition for builders, toolchains, options etc.

Sergei Kovalchuk.

On 2020-02-11 08:39, Alexander Fedorov wrote:
Hi Marc-André,

EMF and Xtext, and Eclipse Platform itself are all to switch from
re-inventing the standard existing solution to focusing on
domain-specific problems. And the current CDT source base is the
perfect illustration of that kind of "re-inventing" - it contains a
lot of over-verbose code with wrong usages of the platform, which
required enormous effort to be created and wants even more to be

Java itself was also good to mention: the idea to isolate memory
management released so much energy that it was successful despite the
initial performance problems. Generally, the idea to separate
expertise is quite effective if we can establish "experience exchange"
between different expertise areas.

And this is exactly what we are looking for: C/C++ experts can
formulate "what" should be done for platform/modeling experts who can
find better way "how" to make it happen. The result should be
extensible enough: i.e. it should be easy to write a textual
configuration file (target definition, toolchain definition, etc.)
using simple text editor without any "Java coding" or "Eclipse coding"
at all.


11.02.2020 0:39, Marc-Andre Laperle пишет:


I haven’t followed all of the details of the thread closely but
one thing to consider is the barrier of entry for extenders who want
to plug into managed build. Using something like EMF or Xtext is
probably more elegant from the point of view of an
enthusiast/professional Eclipse developer but most C/C++ developers,
embedded developers, etc are already put off by writing Java so I
have small concerns adding another layer of abstraction through
those framework. In an ideal world, I would be curious to see
Managed Build be “modelled" only in pure Java with very small
extension points. In any case, I personally won’t need Managed
build or have time to contribute to it so all I can contribute is a
general feeling towards it :)
With this said, I do think EMF and Xtext are cool technologies.


On Feb 5, 2020, at 9:16 AM, William Riley
<william.riley@xxxxxxxxxxx> wrote:

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

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.


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On
Behalf Of Liviu Ionescu
Sent: 01 February 2020 19:05
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Future of Managed Build

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

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



cdt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit [1]

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
cdt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit

cdt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit

cdt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit

Back to the top