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?

All

Thanks for the input. It really is appreciated.
I grouped the input of Christian, Leo and Chris below

While working on the code I also have another burning question.

What is the reasoning to make the toolchain a child of configuration and not project type? There must have been fierce debate about a choice like this (well ther would have been if I was on the project ;-) )

Best regards

Jantje

jan <jan@xxxxxxxxxx> wrote:

1) Is there added value to the Build variables? It looks like they are treated like standard variables to me.
I think it is also confusing (which ones overwrite the others) So I'd like to dump them.
Anyone knows a good reason not to do so?

We need to be able to contribute variables with configuration-dependent values. org.eclipse.cdt.managedbuilder.macros.IConfigurationBuildMacroSupplier allows that, while org.eclipse.core.variables.IDynamicVariableResolver does not. (I don’t know if there would be any other ways.)

 -Christian
I do for sure need environment variables.  Sloeber stores it's data outside of the CDT storage provisions and uses environment variable providers to provide the data to MBS where the commands are coded like ${c.to.o.recipe}.

My question is: As you can see in https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.cdt.doc.isv%2Fguide%2Fmbs%2FextensibilityGuide%2FManaged_Build_Extensibility.html (image below) there are macro's and environment variables.
As far as I can see the macro's are converted to environment variables and have no extra functionality that actually can be used.
If I see this right (and I have been wrong before) there is no use in keeping the macro's. As it clutters the code and the gui and creates confusion.



I used to work on Managed Build with Leo.  It's been a LONG time but I'll try to go from memory.  I don't often read messages here any more in detail but this caught my eye.


As far as I understand one is to load from the plugin.xml (currently the only thing left in my code) one is to create in the toolchain editor and one is to read from "any xml file".

There's a distinction between reading the toolchains as defined by extension point contributions, and the persisted data for a particular project.  The latter captures not only build settings the user changed from their defaults but also the toolchain as it was at the time that the project was created.  You might for example create the project in an IDE that had version N of your toolchain, but then later you load the project in an IDE for which you have version N+1 of the toolchain, and have to perform conversion of settings, or whatever.

- Chris

Thanks for this input Chris. Having input/confirmation on my perceptions/thoughts/ideas from the original developers is good. After all you did this already a long time ago in such a good way that I'm willing to redo it. (That is a big compliment to all of you🎖)
The confirmation that the "build settings file" and the "plugin-manifest" use the same schema is important to me. I was not aware of that and I guess many in the CDT area are not as well. To me this link causes huge versioning issues (mostly because the plugin model is data to MBS provided by a third party that MBS needs to do data conversioning on :-( ).
As you mention the problem of versions It confirms the pain I feel when I read the code.

To explain what I tend to do: Below is a drawing from the current documentation of MBS

Build model logical elements

I made this adaptation to explain how I see MBS and what I try to do.
blue and red are existing components/lines I added to the drawing or renamed existing components.
Red is to be remove in new MBS.

IMHO removing the dual storage use of buildDefinition schema means 2 things
A) we can remove part of the schema related to the storage of the selected options
B) Versioning can be made simpler (note: Everything is implementation dependent; but linking the 2 is making things more difficult)

My current plan is to implement the build settings file as the serialisation of a list of IResource;ITool;IOptionCategory;IOption;IOptionvalue.
This model makes that changing the project type or the toolchain -but keep the same tools- does not require a migration for the build commands to have the same build parameters (in regards to the build options and if you do not have a different command line generator ...)
View ideas are welcome


I can assure you that all of the elements in the schema were required to support a compiler like Microsoft Visual C++.
Leo

Hi Leo thanks for your response.
As you can see from the comments above I'm planning to cut the dependency of the build settings file from the build definitions. As the build definitions contain more data (user input) then the plugin.xml there must be items in the schema that are no longer needed after the cut is made.

Note that in the mean time I gathered all MBS Build definitions in the CDT repository and I found no references to project, fileinfo, folderinfo, resourceConfiguration in the plugin.xml.
While doing so I noticed that the definition of the project confirms my thinking "The project element is an instance of a projectType element.  It appears in the .cdtbuild file, not in an extension definition."

If you think that after cutting the dependency of the build settings file from the build definitions there is still a need for any of these schema elements (project, fileinfo, folderinfo, resourceConfiguration) can you please give an example?
Please tell me if I'm wrong here as if I'm wrong I'd better stop spending time on this.

Thanks

Jantje





    

  

























  Back to the top