Re: [cdt-dev] Is there interest in a rewritten managed build?
I have succeeded in running a test that creates a project based on a xml
in plugin.xml; creates the makefile (not a good one but one anyway) and
start the build.
On can also create the project with the CDT wizard and build.
The project type and schema ID are still hardcoded but that should be a
The environment variables are needed to start the build.
So basically I now have one thin line going from start to finish and I'm
now working on making the line bigger/stronger.
This may sound basic but I think it is a big achievement because MBS is
now working more the way I like it :-)
Next step is to make the makefile work and get the hardcoding of the
project type removed.
And clean clean clean
Apart from the continuing discussion below I have some new questions.
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?
2)The schema does not only contain "field descriptions" for model input
but also for storing values. I'm thinking about folderInfo fileInfo and
As I removed data storage from the model these have no real value except
for ... something I'm missing.
Anyone knows about a usage for them?
Op 24/01/2023 om 9:35 schreef Christian Walther:
Jan Baeyens <jan@xxxxxxxxxx> wrote:
1) Does anyone use (or knows someone who uses) the internal builder?
From Indel, no to both. And in fact, I would be interested in the answer as well, because of the recent interest in https://bugs.eclipse.org/bugs/show_bug.cgi?id=72965 where reviewing a patch to the internal builder would be involved.
I do not see any references towards internal builder in that defect. Are you sure you refer to the correct one?
Yes. The phrase "internal builder" occurs 11 times on the page.
Ok I missed that.
I have had these problems. it is one of the reasons I want to clean up
MBS because now it is to difficult to do modifications.
Apart from the fact that I think clean should simply erase the whole
build folder (including the generated makefiles) one could consider
splitting the clean command in the clean rule.
Using the @ could fix the linker/archiver issues.
Internal build however is a different problem.
But if you look at https://github.com/eclipse-cdt/cdt/blob/main/build/org.eclipse.cdt.managedbuilder.core.tests/resources/depCalcProjects/test1DepCalc2/test1DepCalc2.zip you will see the zip contains a .cproject but also a .cdtbuild file.
Here the .cproject does not contain the "buildDefinition extension" but the .cdtBuild does.
Therefore I conclude MBS has a capability to read the "buildDefinition extension"from a provided file. I see some rare usage for "expert users" but it can keep test data out of plugin.xml files. Both are "nice to have" features for little implementation cost.
So I was wondering whether the "buildDefinition extension in a file" feature was used outside of the managed build testing suite -or am I dreaming and is there no such functionality?-.
Thanks for the explanation. No, we don’t use anything of that and I wasn’t aware of it, our definitions are in plugin.xml and .cproject in exactly the same way as when you make a new managed build project in plain CDT. (I thought .cdtbuild was a precursor to .cproject, but I have no idea, I’ve never seen one.)
3) Does anyone use (or knows someone who uses) the toolchain editor (project properties->C/C++ build->toolchain editor)?
We don’t, and if I remember correctly, deeming it unsuitable was one of the reasons why we built a system of switching between different toolchains (different versions of GCC for different targets, and now also Clang) on top of what is a single toolchain to CDT/MBS. One of those early decisions that I would want to revisit if we were to start afresh.
I'm all ears about reasons of the different toolchains. Apart from having different options for the tools I can't see a benefit. I realize that this used to be different (way more differences between the tools and less standardisation) which forced the creation of this extra component; but I think today the benefit does not outweigh the disadvantage of using the same name for the provider of the tools as the linking between the tools.
It is one of the components that -if I do a sloeber only MBS- will be dropped; because the Arduino framework provides the command line (including the options) and a folder to the tools.
But when I read "and now also Clang" I think "maybe I'm missing something".
If I understand the question correctly: The reason why the addition of Clang is pushing the limits of our single-CDT-toolchain model is that there is not a 100% overlap between command line options of GCC and Clang. E.g. the options for generating an assembly listing interspersed with C source lines are different, the Clang assembler doesn’t understand some options that are useful on GNU as, the way of passing options to the linker is different. So I ended up having to add differentiation facilities on our layer that might already have been solved on the CDT layer if we had modeled GCC and Clang as separate CDT toolchains (but that is speculation).
Now I think this feature is handy/usefull and even needed. But it should
be named something like "tool provider".
This could direct the discovery and the command line options(as it
cdt-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev