Hi All
I've now published the current state of a prototype of a new managed build system to GitHub [1]. This is something I started developing using feedback from the CDT summit at
EclipseCon Europe in 2018. I've not been able to develop this a fully as I intended yet due to other work commitments, but given the discussion on Managed Build is progressing I wanted to publish what I have so far.
There is some documentation of the aims & rough design ideas in the repo readme.md & linked in other files. I'm happy to answer any questions. Nothing in the design is really
fixed, the prototype was to act as a starting point for more detailed discussion.
This system is intended to replace the current managed build system with a simpler implementation which can also be more easily used outside of an Eclipse IDE. This system
is intended only to support using external build systems (e.g. Ninja or Make), though it would be possible to add an extension to provide an equivalent of the current internal builder.
Toolchains and build configurations are specified using Xtext DSLs. The idea being that no Eclipse Plugin development work should be required to create a new toolchain definition
or extend an existing one to add a new tool. Xtext allows the creation of both text and graphical editors within an Eclipse IDE, but also will allow integration with Language Server Protocol compatible editors.
Most of the actual build logic, such as determining build ordering, checking dependencies, determining when to rebuild is intended to either be delegated directly to the external
build system. Where an external tool does not provide that functionality then it will be handled by the build system specific extension rather so that it can be done in a way which works best for each build system. e.g. Ninja will handle rebuilding of files
when options change without additional work, whereas make requires either specifically written makefiles or some external checks.
[1]
https://github.com/Kummallinen/cdt-new-managedbuild-prototype
Regards
William
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx>
On Behalf Of Jan Baeyens
Sent: 20 February 2020 01:38
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Future of Managed Build
Thanks Jonah
I created an account and put some data there.
https://hackmd.io/lIbRv7D-RBepzBTKnWosGg
I think there is enough data there now to do some serious thinking/discussion. I would like to focus on the "use case diagram" first. At this point I do not think the problem domain adds/overlaps with the use case diagram and we will need to agree on the
use case diagram to get some common ground/understanding.
At this point in time I do not see how this will work and it already looks dauntingly complex to me :-S
Hoping for lots of input
Jantje
Op 19/02/2020 om 21:41 schreef Jonah Graham:
A google doc or hackmd.io is fine, someone should link it from the wiki. I have been using
hackmd.io for the call minutes and I quite like it.
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
> https://wiki.eclipse.org/CDT/designs 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
>>>>>
https://www.eclipse.org/mailman/listinfo/cdt-dev [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
>>>>>
https://www.eclipse.org/mailman/listinfo/cdt-dev
>>>>
>>>> _______________________________________________
>>>> cdt-dev mailing list
>>>> cdt-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/cdt-dev
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1]
https://www.eclipse.org/mailman/listinfo/cdt-dev
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
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
|
