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?


Sorry for the long writing but I think there is lots of confusion in how MBS works and without getting a common ground on how it works it is hard to rewrite MBS with confidence.
Thanks for sticking with me


Op 31/01/2023 om 9:59 schreef Christian Walther:
Jan Baeyens <jan@xxxxxxxxxx> wrote:
What is the reasoning to make the toolchain a child of configuration and not project type?
Different configurations need to be able to use different toolchains?

(Which, as previously mentioned, is functionality we are currently not using but reimplementing ourselves on a different layer, which I’m questioning, being unaware of the exact original reasons for the decision.)

Again I 100% agree with the need for a different toolchain per configuration. My idea was to select the ProjectType per configuration. When I read my proposal again I realized things are not as clear (in my head) as they should be. This is why this discussion helps me a lot. Thanks.

I think lots of the confusion is due to naming and implementation and it being a tough subject to get your head around.
Just so we use the same naming (here is my current understanding):
Conceptual tool:The tool we associate with a abstract action. Like compiler or linker.
Actual tool:A concrete existing implementation of a Conceptual tool provided by a ToolProvider. Like the Microsoft visual C++ compiler.
ToolchainType: A collection of conceptual tools with the inputTypes they accept and with the outputTypes they generate. The ToolchainType is described in the toolchain field in the plugin.xml.
ToolProvider: An identifier of a set of actual tools. To be useful for a toolchain a ToolProvider needs to satisfy all the conceptual tools needed for a toolchain. Like mingw, AVR, SAMD.
ProjectType: A template to create an actual CDT project. A projectType needs at least 1 toolchain and 1 configurationType.
Configuration: A way to use the same source code to do something else. Like building for windows and linux.
ConfigurationType: A template to create a configuration. A ConfigurationType must know the ProjectType;
Toolchain: A actual implementation of the ToochainType combined with a toolProvider and A set of options.
(maybe we should rename Type to Template but inputTemplate and outputTemplate does not feel right to me)

The problem I see with having the toolchain under the configuration in the current MBS implementation
When a project is created from a projectType with 2 configurationTypes each with their own distinct toolchain you get all toolchains in your project. However as soon as a configuration gets lost you can never get that toolchain back.
Problem 1: as there is no constructor for a new toolchain based on the configurationType of projectType you can not introduce a deleted toolchain.
Problem 2: When a new version of the projectType contains a new configurationType with a new ToolchainType; you can not introduce this toolchainType in existing projects.
Problem 3: Because you can rename the configurations there is no guaranteed way to know which toolchain is being used (except for: building the project).

If you look closely at the toolchainTypes in the plugin.xml's of the CDT repository you will find that they are basically the same. Some superclass the toolchainType itself others contain the exact same ToolTypes superclassed by the same ToolType.
The only real differences I encountered are different options and different build properties.
My point is: I have not yet seen an actual ProjectType containing configurationTypes with actual different ToolChainTypes; (except for options and BuildProperties that can be dealt with differently).

Question: how can MBS have different toolchains per configuration if the toolchainType is the same?
The answer is: You create the "mother of all your toolchains" which contain "all tools for your projectType".
Using enablements you disable tools using buildProperties. You can override buildProperties in the gui (naturally only if supported by the gui ).
So instead of selecting the tools in the toolchainType the toolchainType has "the mother of all toolchains" as superclass and MBS selects the tools dynamically by comparing buildProperties in the "mother of all toolchains" defined in the same plugin.xml by the once in your project configuration.
To say it mildly: I'm not a fan of this enablement feature :-(.
To proof this is true: Below is a screenshot of a workspace where I created 2 managed build C++ projects. An executable and a shared library. I modified the project so they create the exact same makefile (and that is easy).

My original thinking was that the ProjectType should be selectable in the project properties and can be different per configuration. Only selecting the ProjectType means the ToolChainType must be under the ProjectType.
This discussion learned me that selecting a projectType and a configurationType is required per configuration. The configurationType is needed as MBS needs the answer to the question "derived from which ConfigurationType?". Therefore in this case it does not matter that the ToolchainType is under the ConfigurationType or ProjectType.
In my current understanding the new solution will allow to select a ProjectType/ConfigurationType per configuration. From the image above I want to replace the "Tool Chain Editor" by a "Project Type selector" where you can select a ProjectType and ConfigurationType per configuration. In this solution only selecting the "Artifact name" in the "Build Artifact" makes sense.
Would that work for you?

FYI: I'm still convinced it would be better to have the ToolchainType under ProjectType (but less ;-) ).

As far as I can see the macro's are converted to environment variables
Where do you see that? I don’t recall having ever seen anything like this, and a quick experiment with putting "set" in a pre-build command (on Windows, would be "env" on Unix) seems to disprove it as well.

Maybe you meant to say the opposite – all environment variables are also made available as macros, even the ones contributed by a configurationEnvironmentSupplier. That seems to be confirmed by a quick experiment, so I guess it would indeed be possible to do away with some configurationMacroSuppliers and replace them with configurationEnvironmentSuppliers. It seems weird though to litter the environment of build tools with all that Eclipse-internal stuff.

I'm talking code wise: The resolving of strings inside MBS happens with the CdtVariableResolver as you can see here
Maybe not everywhere and maybe there are other use cases; therefore I'm reluctant to remove the Macro related classes.

FYI: IMHO this is not Eclipse-internal stuff;  it is all(?) CDT stuff. For instance CDT has a variable provider that provides the environment variables of the OS (I know for sure as one of the rare contributions to CDT I succeeded to contribute is: removing the uppercasing of environment variables in windows)

and have no extra functionality that actually can be used

Macros can be either string-valued or list-valued. I don’t think there’s a built-in way to use environment variables as lists?

I agree there is actual extra functionality in Macro's. But what I do not know is: "how can a user use this extra functionality?". Can you provide a hands-on example of using Macro lists that has real user value?


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

Back to the top