Re: [cdt-dev] Is there interest in a rewritten managed build?
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.
> 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).