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 John

Thank you for showing interest. ;-)

I'll try to answer your questions as good as I can.

Why did you need to modify the CDT managed build system (MBS) extension point schema?

The current gnuMakeFileGenerator always put input files at the same place. To really support the Arduino framework Sloeber has to put the input files of the type archive on the command line on a different place from the input type object files during link time. (link <bla bla> ${archives} <more bla bla> ${object files} <Another bla bla> ${output files} <last bla bla>)

So I decided to completely rewrite gnuMakeFileGenerator to get that to work. However doing so I learned this was a extension point schema limitation. I also noticed some other things that made me want to change the extension point. So to list them:

1) output type assumes multiple extensions/names but you can have multiple output types for the same tool which seems redundant to me.
2) I did not see a way to reuse an extension point field to code the "assign to command variable" what I needed to fix the problem described above.
3) the primary input and output make no sense to me at all.
4) Nor does the multiple of type
5) confusing names: outpuType->outputs is actually a list of file extensions
6) To mutch unfinished business

As we all know the quality of the implementation of MBS has degraded over the years and I have been looking at rewriting it for some years now. To me this was the drop that made the bucket overflow; so I decided to try to rewrite MBS fully.
As I realize this is a daunting task (with limited success rate expectations) I first wanted to get enough confidence in pulling this off before talking about it.

How does the feature set of the revised MBS differ from that of the existing CDT MBS?

I try to keep the feature set as close as possible. However:
* If this is not going to be -in some way or another- part of CDT I will solely focus on getting Sloeber to work.
* I doubt some features ever worked (properly) (like editing the extension point in the gui)
* As there will be an extended transitionary period where both will run in parallel there is some renaming involved
* As the feature set is extensive it is nearly 100% sure at least some features will have disappeared. As we will have a cleaner code base adding these features should be easier. (No guarantees)

The rules I have acted upon right now are:

1) For the model a output Type is one file with 1 name or 1 extension (multiple files need to be modelled with multiple output types)
2) Remove primary input/output
3) removed multiple of from the model
4) remove everything deprecated.
5) Remove editing of the model (I mean Sloeber reads the selected model from file and works with that. No ad runtime adding/removing of input types/tools .... ; Selecting a different extension point is on the table)
6) support for multiple extension points and extension point schemas (I see this as the best way to handle versions)
7) Remove the current version code
8) The interface classes of the providers to the model are open for change (and some have already)
9) The generated makefiles are a technical step so they do not have to be human readable.
10) Environment variables and build variables are used via cdt.envvar

Stuff that I would delete if it was a Sloeber only thing but I'm open to discuss if it is part of CDT are:

1) removal of toolchain (note toolchain is used for multiple things; here I refer to cross gcc; microsoft visual C+++, gnu win ...); Use a environment variable to point to the toolchain binary path
2) removal of internal builder
3) removal the cross compiler prefix
4) The sense and nonsense of build variable provider next to an environment variable provider
5) disablement of make file generation.
6) removal of outputType->namePattern
7) remove additional inputs from the extension point schema

How does the user interface differ from that of the existing CDT MBS?

User interface is not my thing so I hope to be able to reuse as mutch of it as possible. However the stuff described above will have GUI impact.

To me it would be great if CDT created a "scanner config nature" and an "environment variable nature" that would activate the user interfaces for these parts. These components are active in my code right now but not visible in the gui.

The MSB specific stuff I'm rewriting
1) a different project creation wizard
2) The toolchain editor will be removed
3) Hopefully a "extension point selection" page will be added.
4) The MSB pages will have to be moved/refactored as they work on different classed and previous work may have created incompatibilities.

How I look at autoBuild

I think the makefile generation is a technical part of the build. Therefore :
* A clean should not be the clean of make but delete all the build output including the generated makefiles. (In Sloeber a clean is not always enough)
* The makefiles do not have to be human readable.
* There is only one way to create make rules. (FI current implementation allows support for * or explicit file listing. AutoBuild only support explicit file listing)
* There should be only one makefile

Don't forget this is a long and difficult project. I may know where I am today and I may think I know where I hope to end up; but "Man proposes, God disposes.". This puts me on a difficult balancing point between using as little resources of CDT team as possible and still get enough input.

I guess this is enough for now.

Best regards


Op 4/01/2023 om 17:15 schreef John Dallaway:

Hi Jantje

To help us all respond to your question, can you please briefly comment on the following points:

  • Why did you need to modify the CDT managed build system (MBS) extension point schema?
  • How does the feature set of the revised MBS differ from that of the existing CDT MBS?
  • How does the user interface differ from that of the existing CDT MBS?


John Dallaway

On 01/01/2023 20:32, jan wrote:

Hi all,

I have been working on rewriting part of managed build. That is; I needed a new extension point because I needed to modify the extension point schema.

I have gotten to the point where I have the basic framework -based on the original code- running from a different extension point (io.sloeber.autoBuild.buildDefinitions).
There is still plenty of work (months to a year I think).
The steps I plan to take are

  1. Copy/modified code to get the basic framework to run. (done)
  2. get a functional part working
  3. add runnable testsĀ  (used for regression testing)
  4. cleanup/rewite the functional part.
  5. If parts remaining goto 2

During cleanup I will have to take important decisions that will decide on the reusability.

I'm thinking about

  • Do I keep the toolchains, the versions, the build variables...
  • How far to cleanup the extensionpoint

An important driver for me will be: "Will this ever become part of CDT" because if not the only criteria is "Does sloeber need this".

Therefore I would like to know whether there is interest in this?

Best regards


The current mess of code can be found at

The 2 plugins you need to add to CDT are io.sloeber.ManagedBuild and io.sloeber.ManagedBuild.ui

cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top