Author Topic: How to expand compiler variable containing spaces without quotes (Read 11303 times)

ondra.holub · « **on:** September 26, 2011, 03:47:54 pm »

Hello.

I have a compiler custom variable, which defines some compiler specific options for a certain library. They are of course different for different compilers and different platforms. Is there a way to expand such variable in Project->Build options|Compiler settings|Other options to be without double quotes?

For example when I have compiler variable COMPILER_OPTIONS set to -a -b -c I want to get in compiler's command line -a -b -c, not "-a -b -c". Currently I have compiler variable set to -a -b -c and in compiler options I have $COMPILER_OPTIONS. I tried $(COMPILER_OPTIONS), ${COMPILER_OPTIONS}, %COMPILER_OPTIONS% as well, but all of them are expanded with double quotes.

The only workaround I have found is to define COMPILER_OPTION1, COMPILER_OPTION2 etc. and use all of them (some of them may be empty). But this is quite ugly.

Thanks for any hint,
Ondrej

Freem · « **Reply #1 on:** September 26, 2011, 09:04:17 pm »

Did you try the backslash?
When I use auto completion in folders with spaces in my terminal (I'm on Linux, so I'm not sure it will be portable on MS's OSes) it prefix spaces with them.
By example: "cd my\ dir"

But, why don't you use "other options" tab and the target system? It is made precisely for this kind of problem...

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.

Alpha · « **Reply #2 on:** September 26, 2011, 11:05:38 pm »

Assuming these are the type of variables you are talking about, the way I worked around it was by setting up the variable, saving the project, and closing Code::Blocks. I then opened the project file (*.cbp) in a plain text editor (Notepad). In the editor, search for the value of the variable (-a -b -c), and delete the string " from in-front and behind it. Upon reopening the project it "should" work.

However, for your situation it sounds simpler to do what Freem suggested.

Quote from: Freem on September 26, 2011, 09:04:17 pm

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.

ondra.holub · « **Reply #3 on:** September 27, 2011, 08:53:37 am »

Thank you for hints. Well - create two targets dedicated to different platform (in my case linux and windows) is working solution I was using before. I have grouped "same" targets for different platforms to a single virtual target (for example "gcc all") and on each platform is the not matching target simply skipped. Maybe I will return to this approach.

The reason, why I wanted to define it this way is: I have more than one project using wxWidgets. Sometimes I change (upgrade) wxWidgets installation to a newer version. My idea is that then I will redefine some Code::Blocks variables and all projects remain working, because compiler's options are defined indirectly via these variables.

In meantime I have found other workaround which is enough for my usage: When I need to define additional parameters via some variable - for example -a -b -c I can define the variable as -a" "-b" "-c - it is expanded to "-a" "-b" "-c" which is correctly passed as command line arguments to compiler.

oBFusCATed · « **Reply #4 on:** September 27, 2011, 09:37:39 am »

ondra.holub: can you give detailed steps for reproducing this problem?

ondra.holub · « **Reply #5 on:** September 27, 2011, 12:01:43 pm »

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 · « **Reply #6 on:** September 27, 2011, 01:10:18 pm »

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>

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 · « **Reply #7 on:** September 27, 2011, 03:31:38 pm »

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.

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 · « **Reply #8 on:** September 27, 2011, 03:57:42 pm »

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"

?

thomas · « **Reply #9 on:** September 27, 2011, 07:39:57 pm »

Quote from: BentFX on September 27, 2011, 03:57:42 pm

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.

Quote

As far as quoted paths and compiler options go, shouldn't it be possible to do...
-I "C:\My Dev Stuff\include"?

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 */?...

MortenMacFly · « **Reply #10 on:** September 27, 2011, 08:13:20 pm »

Quote from: thomas on September 27, 2011, 07:39:57 pm

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?

killerbot · « **Reply #11 on:** September 27, 2011, 10:04:03 pm »

I think Martin has a point, I was thinking along the same line. Just like the $TO_ABSOLUTE_PATH macro, or whatever I called it ;-)

thomas · « **Reply #12 on:** September 28, 2011, 01:34:33 pm »

$REMOVE_QUOTES{} might indeed be the solution. Quite a good idea.

Jenna · « **Reply #13 on:** September 28, 2011, 01:59:32 pm »

Quote from: MortenMacFly on September 27, 2011, 08:13:20 pm

Quote from: thomas on September 27, 2011, 07:39:57 pm
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.

oBFusCATed · « **Reply #14 on:** September 28, 2011, 02:08:41 pm »

Now someone should implement it :lol:

MortenMacFly · « **Reply #15 on:** September 28, 2011, 08:35:33 pm »

Quote from: oBFusCATed on September 28, 2011, 02:08:41 pm

Now someone should implement it :lol:

Done in trunk.

BTW: I figured out a bad "bug":
What does not work for all these macros is something like:
$TO_ABSOLUTE_PATH{%APPDATA%} (on Windows, for example), as the platform specific macros (environment variables) are being replaced at last (which HAS to be like that!). Unfortunately this spoils things I had in mind with the TO_PATH_83 macro. I don't have a good solution other than for these (path's related) macros check for inner platform macros first that point to path's, but this seems very hacky to me. :-(

Does any of you have a good idea for these cases?

Oleg_Sam · « **Reply #16 on:** November 28, 2011, 01:38:08 pm »

The $REMOVE_QUOTES{} macros is not work on CB svn7549 Debugger Branch on WinXp SP3.
To reproduce it :
1. Create any project, for example, Console Application
2. Build this Project, all works OK.
3. Create Custom variable ADD_OPTIONS = -Wextra -Wmain (the quotes is automaticaly added)
4. In Compiler settings -> Other options type $REMOVE_QUOTES{$(ADD_OPTIONS)}
5. Build this Project.. after this CB is hangs up and crashes

Thanks.

oBFusCATed · « **Reply #17 on:** November 28, 2011, 02:57:35 pm »

Does it work with the normal nightly?

Oleg_Sam · « **Reply #18 on:** November 28, 2011, 03:11:31 pm »

I dont know, because I use only debugger branch..

Oleg_Sam · « **Reply #19 on:** November 28, 2011, 03:32:05 pm »

I just test it on normal nightly svn7550, and this macro also not work and CB crashes

Oleg_Sam · « **Reply #20 on:** November 28, 2011, 05:57:58 pm »

When I type $REMOVE_QUOTES{"-Wextra -Wmain"} on Compiler settings -> Other options
it works fine. I suppose, that global variables not replaced in this macros.

Thanks.

News:

Author Topic: How to expand compiler variable containing spaces without quotes (Read 11303 times)