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
