User forums > Using Code::Blocks
How to expand compiler variable containing spaces without quotes
ondra.holub:
Steps to reproduce:
* create any new project (let's say console application - default 'Hello world' can be used)
* From menu select Settings -> Compiler and Debugger
* Select Global compiler settings
* Select gcc compiler
* Select tab Custom variables
* Create new variable VARIABLE with content -a -b -c
* Click OK
* Select from menu Project -> Build Options
* Select tab Compiler settings and sub-tab Other options
* Add $(VARIABLE)
* Click ok
* Build project - it will of course fail, because there are unknown options
* Look into Build log - you will see in command line "-a -b -c" (with double quotes)
Code::Blocks windows version svn 7452
Code::Blocks OpenSUSE linux svn 7215 32-bit
BentFX:
It seems you can edit the default.conf and remove the quotes on the variable. From my limited testing it appears the variable is maintained and available for new projects, until you edit it again in Settings > Compiler and debugger... Then C::B puts the quotes back in place. You can view it in settings and see the quotes are removed, just can't edit it without the quotes coming back.
It shows up in the ~/.codeblocks/default.conf in context such as this... (not sure where it's hidden in Windows)
--- Code: ---<custom_variables>
<VARIABLENAME>
<str>
<![CDATA["-a -b -c"]]>
</str>
</VARIABLENAME>
<VARIABLE_REPAIRED>
<str>
<![CDATA[-a -b -c]]>
</str>
</VARIABLE_REPAIRED>
</custom_variables>
--- End code ---
In this case $(VARIABLE_REPAIRED) should compile.
Close C::B before editing default.conf.
This of course isn't optimal, but if it is a real issue it should make it workable until there's a fix.
thomas:
--- Quote from: BentFX on September 27, 2011, 01:10:18 pm ---This of course isn't optimal, but if it is a real issue it should make it workable until there's a fix.
--- End quote ---
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.
If the macro substitution did not quote strings with spaces, path names that contain spaces would break, which would make a lot of people (especially Windows users) very unhappy. Think of paths like C:\Documents and Settings\Blah User\develop, which a lot of people use.
The only thing I could think of as a workaround to make -a -b -c work as intended by the OP would be a special "treat this literally" code, in the way Excel cells starting with ' work, for example. One would need to be extra careful with such a thing though, so it won't interfere with something else.
Unluckily, again, -a is a perfectly valid filename too, so one can't just assume that anything starting with '-' needs special treatment as non-filename.
BentFX:
Hi Thomas,
Possibly a "Save unquoted" checkbox?
There is also the possibility that we could assume anyone who is setting compiler options, is "with it" enough to quote their own strings. I mean the string that needs quotes would fail till you fixed it, or else the string that needs to be literal fails all the time??
As far as quoted paths and compiler options go, shouldn't it be possible to do...
--- Quote ----I "C:\My Dev Stuff\include"
--- End quote ---
?
thomas:
--- Quote from: BentFX on September 27, 2011, 03:57:42 pm ---Possibly a "Save unquoted" checkbox?
--- End quote ---
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.
--- Quote ---As far as quoted paths and compiler options go, shouldn't it be possible to do...
-I "C:\My Dev Stuff\include"?
--- End quote ---
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.
Whatever it is, one must also consider that there are a few thousand people who have been using this for half a decade on some hundred thousand projects, thus we cannot easily change the behaviour, or we risk well-deserved hate mail.
Personally, I'd puke if I'd have to manually edit each and every project from the last 5 years just because someone decided to change program behaviour. Likely, a lot of users will be like that, too.
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.
Such a thing must be easy to type on any keyboard, regardless of localization, and won't occur in a filename or a commandline option, so for example something like !!!. Then again, under some operating systems, it is perfectly legal to have a file named !!! or */?...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version