| Re: [cdt-dev] Is there interest in a rewritten managed build? |
All
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
Jantje
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 variablesWhere 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
https://github.com/eclipse-cdt/cdt/blob/main/build/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/internal/macros/BuildMacroProvider.java#L238
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 usedMacros 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?
-Christian _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev