Escape '$' character in project options

[rjmyst3]

Hi all,
 First: Code::Blocks is quite fantastic. I use it in both Ubuntu 6.06 and Windows XP SP2, and I love it! Great work!

 I have a question:
 Is it possible to escape the '$' character in the project options, such that it is NOT interpreted as the start of a build variable?
 I'm trying to add an rpath to my project (in linux). I want the value of the rpath to be $ORIGIN/lib. Is there any syntax that I can use so that the $ORIGIN will actually reach the linker's command line?

 Right now I've got it to work by "cheating" with backticks - this is the exact text that I have in the "Other linker options" box:
 

Code

-Wl,-rpath,$``ORIGIN/lib

The backtick expression resolves to nothing, and I get the desired result.

 Is there a better way to do this?

Thanks

[thomas]

This is currently not implemented.

Unluckily, it is not entirely trivial to do either. For one reason, \$ will not work because \ is used as path delimiter under Windows. Using $$ to escape $ might work, but since variable replacement works recursively, we would have to do a hack like replacing it with a temporary token and replacing that one back at the end...
I'll think about it after getting some sleep.

[thomas]

Had a look at it and tried the substitution/back-substitution idea. Unluckily, it is not quite so easy with the current build system, as the same parameter is passed through macro replacement 2-4 times (depending on what it is). This is due to historical reasons: back in the old days, compiler variables were registered as enviromnent variables in a first pass and looked up later in a separate pass.
Consequently, the substitution/back-substitution approach fails in the second pass.

It would require a bit of a bigger hack to make it work (unless one is willing to rewrite the existing build system just for this, which does not make sense). One could do the final back-substitution in the compiler plugin, just before the commandline is passed to the sub-process. This would do the job, but it would be quite bad style (that operation does not belong into this module).

The other option would be to rewrite the build chain so macro replacement runs over the commandline exactly once, which would be the correct thing to do anyway. However, the risk of breaking something major for a relatively minor feature is quite big (we've had that before), so I am afraid that'll have to be postponed for a later occasion.

[rjmyst3]

That sounds fine to me. I have a workaround in place, so I have no problem being patient. I'm sure you guys will take care of it when the time comes.

Thanks for looking into it, and thanks for a great app!