[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Is there interest in a rewritten managed build?
|
Hi all
Thanks for the input. I learned a lot.
>What happened to the efforts to build a new managed build
system based on core build anyway? (Where I confess I never
contributed either.)
Good question. I don't know. Never heard about it.
I'm not asking for contributions. I just want to evaluate whether
it is worth to put in extra effort to make my work (rewriting
managed build) more generally usable.
>CDT's answer to this trend is the Core Build flow.
And again never heard of Core Build flow. It may have been a
better way to get Sloeber going. Who knows.
I think the answer to my question: "Is there interest in a
rewritten managed build?" is "Depends on how good it is"
And there the problem is "According to specs it is great; and it
still needs to be implemented :-( "
So I can't make promises. But I do have some questions on MBS
functionality some of you may be able to answer
1) Does anyone use (or knows someone who uses) the internal
builder?
2) Apart from the testing; Does anyone use (or knows someone who
uses) the "extension point in a file functionality" ?
3) Does anyone use (or knows someone who uses) the toolchain
editor (project properties->C/C++ build->toolchain editor)?
For those interested, below is a short description of the road
I'm on.
I copied MBS to another set of plugins and got them to play along
with CDT without being dependent on MBS.
My validation point was "Creating a project via a CDT wizard;
creation of makefiles; starting make". The build failed as the
makefile was bad but that is OK for me as I know why and that is
the part I know already.
Then I started stripping/modifying the code to get to know it and
remove things "I don't like". Each time getting in a rabit hole of
way to many changes before the code even compiles, let alone
create an executable.
One thing I didn't like was that the extension "project type"
instantiation in memory contained project data. So I removed that.
In my mind the extension "project type" instantiation (I call it
the model in the code) needs to be "read only" so I also removed
lots of creation/modification methods (but not all jet :-( ). Now
I'm nearly back at "Creating a project via a CDT wizard".
Internally the build starts but it doesn't get to running make;
because the project has the "not yet created" flag.
I also removed plenty of version stuff. I personally think that
is not needed, let me explain why.
I assume versions are only needed to migrate projects. (Tell me
if I'm wrong)
The new MBS I'm working on needs following information to
create/open a project. Extension point ID (basically the schema);
extension point and project type. The extension point ID is
tightly coupled to the code. So new MBS knows the extension point
ID's it supports (currently none ;-) ) the extension point and
project type are (from MBS point of view) "user data".
The extension point and project type are fully defined within the
limitations of the extension point ID so no versioning is needed
here.(A devil in my head says I'm missing some use cases here; but
then .. MBS can not be responsible to migrate user data)
If new MBS creates a new extension point ID when it changes the
schema the new MBS knows both extension point ID's and can be
provided with upgrade(/downgrade?) code.
So in my mind if there is the rule "Touch the schema (in a
incompatible way) => make a new extension point ID" all(?)
versioning can be fixed within MBS.
Thanks for reading
Jantje
Op 13/01/2023 om 12:01 schreef Mark
Goodchild:
Hi all,
I agree with much of what Alessandro and
Erwin has said.
Our product currently uses managed build.
We have invested heavily in this and on the most part it does
what we need.
We have requirements from customers that
like managed build as it is relatively easy to get started and
there is GUI for setting up the build.
But now it is old and certainly is not
getting much investment.
We also have customers that complain about
the same things outlined in Alessandro’s mail. It is not easy
to use managed build for C.I. and Headless build is not
satisfactory for this purpose, etc., etc.
So our requirements have definitely moving
towards CMake driven build for us too. Partially I think due
to the increase in C.I. usage throughout development teams.
While harder to setup for some users – it
is transparent and easy to customize and integrate many
different tools.
So longer term -> “non IDE dependent
build system is a must have for us” this will also be our
requirement I think.
The question I have is whether it is
possible to bridge these different types of users.
e.g. Provide some simple GUI within the IDE
that sits on top of the non-IDE dependent build system.
This might make CMake type build a more
attractive proposition for novice users.
We did start an initiative sometime back to
consider this for CDT moving forwards.
But sadly we did not make a big enough
investment to really get it going.
Definitely interested in this discussion
moving forwards.
Best regards,
Mark.
I'm a long term CDT USER, me and my team
are developing an embedded Iot Gateway. Our code base is
largely C/C++ that are cross builded for arm processor
we use Linux Ubuntu as HOST developer
workstation and minly CDT as our IDE.
We have a big C/C++ project, our
build system consists of our hand made Makefiles that
automates the build, test and of the entire solution.
We use the same build system in our
CI/CD pipeline.
So using a non IDE dependent build
system is a must have for us, and I think as said by
Erwin is a trend for our industry.
Currently we are using the CDT Managed
Build project / Makefile Project / Tool Chain Cross GCC.
This way CDT invokes our Makefiles and
different configurations call different Makefile Targets
and includes PATH so that CDT builds up its index and we
can navigate easily through the code.
The problem is that configuring the
project in CDT is not very easy and a bit confusing for a
new people
The project files could not be saved on
the repository because they are changed locally by CDT.
I remediate, by committing them in a
relevant folder, then a developer checkout the project ,
then calls a make target that copies the eclipse/cdt
project files to the root folder before opening the
project with CDT.
Another problem is that almost every
time we close and reopen the project in CDT, the CDT cross
tool settings are lost, and so we need to reconfigure them
(fortunately by invoking the target that copy the project
files )
Another problem is that it is difficult
to integrate some very useful tools like c-lang formatter,
C-lang tidy, and other static analysis tools, in order to
have a development cycle not IDE dependent.
I love CDT, but I confess that it needs
some cleaning and simplification.
Hi,
The Managed Build project is like the traditional IDE
where you have full GUI support for setting compiler and
linker flags and so on. The traditional IDE can generate a
Make file or another build script for you.
If you look at the top trending C/C++ projects at github
you see that the trend is to move away from this. People
manage a (C)Make file by hand. There is no need for GUI
help.
The main reason for using an 'IDE' is the code navigation,
smart editing, and a debugger GUI. Visual Studio Code
satisfies these needs and became very popular.
A big advantage of the new way of working is that it
seamlessly fits working on the command line and continuous
integration flows. For teams this is a big plus. One user
can use IDE, the other CLI. And the regressions use the
same (C)Make files.
CDT's answer to this trend is the Core Build flow. I think
it is better to invest in Core Build flow than in Managed
Build. Core Build flow should *not* be turned into a new
Managed Build. It has to stay lean and mean. We need to
get the Core Build Makefile Project out of the
'experimental' state. I think that is the best replacement
for the current Managed Build.
Regards,
--
Erwin Waterlander
Intel
erwin.waterlander@intel
http://www.intel.com/
The Netherlands
> -----Original Message-----
> From: cdt-dev <cdt-dev-bounces@xxxxxxxxxxx>
On Behalf Of Christian
> Walther
> Sent: Thursday, January 12, 2023 18:08
> To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> Subject: Re: [cdt-dev] Is there interest in a
rewritten managed build?
>
> jan <jan@xxxxxxxxxx>
wrote:
>
> > Therefore I would like to know whether there is
interest in this?
>
> Speaking as a downstream integrator who is using
managed build, my
> tentative answer is: Probably not, from us.
>
> While managed build is complicated and quirky, it
mostly does what we
> need, and where it doesn’t, we have patches and
workarounds in place. It‘s
> all a big, organically grown mess (some of our early
decisions turned out
> questionable in hindsight), but it works. I am
skeptical whether transplanting
> that mess onto a rewritten base would be worth the
effort. What you design
> to address your gripes will not necessarily also
address our gripes, at the
> same time I do not have time to contribute to
designing a system that
> addresses everyone’s gripes.
>
> What happened to the efforts to build a new managed
build system based
> on core build anyway? (Where I confess I never
contributed either.)
>
> -Christian
>
>
> --
> Indel AG
> Christian Walther - Software
> Tuefiwis 26
> CH-8332 Russikon
> Switzerland
>
> Tel.: +41 44 956 20 00
>
www.indel.ch
>
------------------------------------------------------------------------------------------
> New product GIN-MAX4x4: The compact 4-axis motion
board now also
> available as PRO version!
>
https://www.indel.ch/en/products/drives/compact-motion-drives
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/cdt-dev
---------------------------------------------------------------------
Intel Benelux B.V.
Registered in The Netherlands under number 24134020
Statutory seat: Rotterdam
Registered address: Capronilaan 37, 1119NG Schiphol-Rijk
This e-mail and any attachments may contain confidential
material for
the sole use of the intended recipient(s). Any review or
distribution
by others is strictly prohibited. If you are not the
intended
recipient, please contact the sender and delete all
copies.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To 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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
