| 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
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.
Thanks,Jonah
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
> 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