Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Update on rewrite managed build?

Here a status update on the rewrite and some questions

I think I made quite some progress but still a long way to go. I implemented the enablements using eclipse expressions and the options are now part of the compile commands. As far as I have tested the new MBS generates the same default commands as the current MBS does.

My current testscript runs 31 tests on Windows (create; build only; no persistency; no modification). That is 31 projects are created (mostly containing 2 configurations); all configurations are build and if an expected result is produced (String[] validOutputs = { projName + ".elf", projName + ".bin", projName + ".hex", ... };) the configuration build is considered successful . The test is considered successful if all configurations compiled successful.

From the 31 tests 9 are successful 22 fail. Still a long way to go but last week it was 0 successful :-)

These 31 tests are from 64 projectTypes copied from the plugin.xml from the CDT repository. These are the ones that are supposed to build on windows.

Untill now I have been working as follows: Write some code; run it; do the same in the current MBS; spot the differences; find out why the difference; fix it.
In other words current MBS is my guide and judge for new MBS. If I cant run it in current MBS; I'm stuck.

Until now my efforts to run clang and microsoft visual c++ projects have failed.
And that is why I can use some input.


I downloaded the windows 64bit compiler here I noticed it is kind of old but for my purposes (validating the build process) I thought that would be fine.
The clang.win32 projectTypes find the tools but do not compile properly. I modified the plugin.xml for llvm to select the outputType of the linker based on the buildProperty set in projectType. Now the makefile seems fine to me (I can't compare to current MBS; see later) but the build fails with

clang++ -o "" "src\main.bc"

clang++: error: unable to make temporary file: no such file or directory

clang++: warning: unable to find a Visual Studio installation; try running Clang from a developer command prompt [-Wmsvc-not-found]

When I tried to create the same projectType in current MBS I could only find clang stuff when I enabled incompatible project types. When I created an incompatible project type the project creation failed.

LLVM is 18 projectTypes/tests. All failed.

Microsoft visual c++

Again I didn't find a blatantly obvious place to download the microsoft visual c++ tools (preferably one compatible with the clang above). But I could create a project in the current MBS and in my setup I could only use the internal builder.
Anyone any idea why only the internal builder was active on my system?
The generated makefiles seem fine except for generating commands to build both the exe and dll. When I look at the model I do not see the selection criteria. The tool clearly contains both outputTypes and there is no enablement to select one.

Am I missing something?

MVC is 3 projectTypes/tests. All failed.

About Macro's

If you read the latest gnu make documentation macro's are hardly mentioned. The word variable is used for the concept of storing strings.
The word Macro is only mentioned 12 times and the word variable is mentioned more than 500 times.
The doc also states: "
Every environment variable that make sees when it starts up is transformed into a make variable with the same name and value." and "In some other versions of make, variables are called macros."
I think it is safe to say the distinction between Macro and Variable has faded in make world.
The only distinction is a "list of values". As a list of values can be stored in a string the distinction is small.
In CDT CdtVariableResolver has the method isStringListVariable which clearly indicate support for string lists.
As MBS does not create stringListVariables itself MBS can do with CdtVariableResolver only except for IProjectBuildMacroSupplier to register buildMacroProviders for the Project.

Practically I have been fighting the options and I think I F*up the stringList stuff but I'm sure when I have a test project it will be fixed easily.

Best regards


Op 2/02/2023 om 20:41 schreef jan:

Op 1/02/2023 om 10:43 schreef Christian Walther:
Jan Baeyens <jan@xxxxxxxxxx> wrote:
FYI: IMHO this is not Eclipse-internal stuff;  it is all(?) CDT stuff.

When I wrote “Eclipse-internal”, I was counting CDT (including MBS and our own extensions on top of it) as part of Eclipse – as opposed to make and build tools that know nothing about Eclipse and CDT.

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?

All I can say is that we are using it, I don’t know if that use adds any value that couldn’t be added otherwise. Our toolchain has tools with list-valued options (resulting in command line options that appear multiple times), and our own code provides the recommended list of values (computed on demand) as a macro. The default value of the option is a reference to that macro, so if the user doesn’t do anything, they get the recommended values. But they have the option of adding more values to the list or removing the macro reference that provides the recommended ones.

         name="INOS config (-k)"

(Usually users don’t need to do anything in the “Tool Settings” tab pictured here, all settings are made on a higher level in our own UI. The main requirement isn’t the ability for the user to customize (we could add that on our own layer if needed), but that we can supply option values programmatically, computed on demand at makefile generation (or indexing) time, ideally without being stored in .cproject.)

Thanks for you input. It seems to me this is a very good example of "how can a user use this extra functionality?"

Given your explantation of options I'm currently assuming the listOptionValue is at least partly Macro driven. As the macro provider is not in MBS this can be a very local usage of IMacro functionality in MBS and therefore hard to spot.

I didn't yet get to the options code but now I know I need to be extra careful in regards with macro's when I deal with that code. Thanks. This was the exact info I was looking for. If there are other use cases you can think of please let me know.

PS: It seems like you're doing pretty mutch the same as I do with Sloeber. Extensive usage of environment variables/macros stored outside of the .cproject to control the build from our own UI.


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

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

Back to the top