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