| [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.
Clang
I downloaded the windows 64bit
compiler here https://llvm.org/builds/.
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 "011_cdt.managedbuild.target.llvm.clang.win32.cygwin.exe_org.eclipse.cdt.managedbuilder.llvm.ui.buildDefinitions.exe" "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]
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
Jantje
Op 1/02/2023 om 10:43 schreef Christian Walther:
Jan Baeyens <jan@xxxxxxxxxx> wrote:okFYI: 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.
plugin.xml:
<option
id="ch.indel.idev.toolchain.indelimage.option.inosconfig"
category="ch.indel.idev.toolchain.indelimage.category.other"
name="INOS config (-k)"
valueType="stringList"
command="-k"${value}"">
<listOptionValue
value="${InosConfig}">
</listOptionValue>
</option>
(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.
-Christian
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
