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