Skip to main content

[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


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,



From: cdt-dev <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Alessandro Fardin
Sent: 13 January 2023 10:13
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Is there interest in a rewritten managed build?


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.




Il giorno ven 13 gen 2023 alle ore 09:55 Waterlander, Erwin <erwin.waterlander@xxxxxxxxx> ha scritto:


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.


Erwin Waterlander                                                 Intel
erwin.waterlander@intel                                   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
> ------------------------------------------------------------------------------------------
> New product GIN-MAX4x4: The compact 4-axis motion board now also
> available as PRO version!
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
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
To unsubscribe from this list, visit

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
To unsubscribe from this list, visit

Back to the top