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

A google doc or is fine, someone should link it from the wiki. I have been using for the call minutes and I quite like it.


On Wed., Feb. 19, 2020, 14:45 Jan Baeyens, <jan@xxxxxxxxxx> wrote:
I wanted to update the wiki and it seems a new policy is in place and I
need to provide personal data among that my home adress, .... to update
the wiki.
I'm not sure I want to do that.
Can we document the future of managed build somewhere else?

Op 11/02/2020 om 16:05 schreef Jan Baeyens:
> Hi All,
> I'm really happy to see the interest in this topic keeps going :-)
> Catching up after a holiday and reading through the thread I'm
> registering following common understandings:
> 1:We are using different languages and this makes communication
> difficult.
> 2:We are talking at different levels
> business/architectural/analytical/implementation and this makes
> communication difficult.
> 3:We are using a mail list and this makes communication difficult.
> 4:We all have very different backgrounds and have different models in
> our heads and this makes communication difficult.
> So time to level up :-)
> Like Jonah proposed I'll try to make a new page at
> which should help with 3 and 4
> The first things I want to add are a problem domain description and a
> use case diagram.
> I think these 2 will help tackle the 2 first items and the format
> should help on the 3th and 4th. Note these are business level (like
> creating a new toolchain) thingies and are completely implementation
> agnostic.
> Question: As I no longer have licences for the tools I used to use and
> eclipse marketplace returns plenty of UML tools .... any advice on a
> free and good UML tool?
> Best regards
> Jantje
> PS: For some of you "problem domain description" and "use case
> diagram" may sound really difficult but they are in fact very simple
> things to get to a common understanding of "what we are talking about"
> (problem domain)  and "what to expect" (use case diagram).
> PPS I realize I have been adding to the confusion by using "model"
> instead of "an example of a diagram based on the model"
> Op 11/02/2020 om 7:24 schreef sergei.kovalchuk@xxxxxxxxxx:
>> 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.
>> BR,
>> 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
>>> supported.
>>> 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.
>>> Regards,
>>> AF
>>> 11.02.2020 0:39, Marc-Andre Laperle пишет:
>>>> HI,
>>>> 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.
>>>> Marc-André
>>>>> 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
>>>>> 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-----
>>>>> 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
>>>>> 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
>>>>> cdt-dev@xxxxxxxxxxx
>>>>> 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
>>>>> cdt-dev@xxxxxxxxxxx
>>>>> To change your delivery options, retrieve your password, or
>>>>> unsubscribe from this list, visit
>>>> _______________________________________________
>>>> cdt-dev mailing list
>>>> cdt-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit
>>> Links:
>>> ------
>>> [1]
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> 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