Open the properties of your project, then, "project's build options", next, go on a target you made for a special target (ie: a special OS, a special compiler, another problem, or a mix of some or all those problems), click on "Other options" tab, and just put your options here.
<custom_variables>
<VARIABLENAME>
<str>
<![CDATA["-a -b -c"]]>
</str>
</VARIABLENAME>
<VARIABLE_REPAIRED>
<str>
<![CDATA[-a -b -c]]>
</str>
</VARIABLE_REPAIRED>
</custom_variables>
This of course isn't optimal, but if it is a real issue it should make it workable until there's a fix.It's unlikely that there will be a fix, because quoting any string that contains spaces is intended (and necessary) behaviour. This is because the "mainstream" use of custom vars is to store pathnames.
-I "C:\My Dev Stuff\include"?
Possibly a "Save unquoted" checkbox?That would be the obvious solution, but since we allow a total of 13 (6 predefined and 7 custom) fields per variable, we would need something like 7 checkboxes. It's pretty safe to assume that the predefined fields are pathnames, but any of the custom fields could be either a single path, several paths, or something else.
As far as quoted paths and compiler options go, shouldn't it be possible to do...Yes, but the problem is that the most common usage scenario is rather something like -I $foo or -I $#bar, i.e. it's the IDE who must supply quotes if necessary. I'm not sure if the regex matches inside quotes either (it shouldn't, unless I made it buggy), and writing something like -I "$foo" shouldn't expand.
-I "C:\My Dev Stuff\include"?
The only thing I could think of which would be realistic to implement and safe enough for backwards compatibility would be to decide for a "literal string" marker, and that can be harder than it sounds.I see another (IMHO much simpler) solution: What about a global macros like $NO_LITERALS{my_string} or $REMOVE_QUOTES{my_string}, similar to the other macros like $COIN, $PATH_83{} or alike we have?
Sounds good to me.The only thing I could think of which would be realistic to implement and safe enough for backwards compatibility would be to decide for a "literal string" marker, and that can be harder than it sounds.I see another (IMHO much simpler) solution: What about a global macros like $NO_LITERALS{my_string} or $REMOVE_QUOTES{my_string}, similar to the other macros like $COIN, $PATH_83{} or alike we have?
Now someone should implement it :lol: 8)Done in trunk.