[
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.
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]
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.
![](pngWp8YtfS7G5.png)
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 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.
ok
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