custom variable string: loading .cbp converts slash to backslash

[J.]

The custom variable LEX_OUTPUT reasonably defined in the .cbp file (see xml snip below) is converted to  '| gawk -f .\FlexOutput.awk >' where the required slash is annoyingly replaced by a backslash in the build options view and when running a build. A nasty workaround is to edit the custom variable every time when the project is newly loaded. 

How can the conversion be avoided - or is this a bug (happy to file a bug if pointed to where to report it)?

Living on Win10 with CB16.01 (Jan 25, 2016).

Thanks,
J.

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
	<FileVersion major="1" minor="6" />
	<Project>
		<Build>
			<Environment>
				<Variable name="LEX_OUTPUT" value="| gawk -f ./FlexOutput.awk &gt;" />
			</Environment>
		</Build>
	</Project>
</CodeBlocks_project_file>

[oBFusCATed]

I think you can use the macro $TO_UNIX_PATH{} around the path.
See here http://wiki.codeblocks.org/index.php/Variable_expansion#Build_in_functions_for_path_conversion

[J.]

Thanks, this does not work unfortunately:

Code

<Variable name="LEX_OUTPUT" value="| gawk -f $TO_UNIX_PATH{.\FlexOutput.awk} &gt;" />

which is what you suggested translates upon a build to

Code

... | gawk -f {.\FlexOutput.awk} > ...

, i.e. $TO_UNIX_PATH is dropped without any impact, but leaving the curly brackets in place.

I checked that - in contrast to functions '$F{}' - variables '$V()' are correctly expanded.

... or am I missing something here? 

[oBFusCATed]

Can you share a minimal sample project that demonstrate this problem?

[J.]

First of all, apologies for this rather lengthy posting! After digging a bit deeper into this issue, here some thoughts on custom variables defined in the build option section Custom Variables:

• Slashes and backslashes in custom variables
  
  • Slashes and backslashes are properly saved as such in the project file .cbp. [EDIT: I just noted that CB insists on converting slashes to backslashes in .cbp files]
  • Slashes are confusingly displayed as backslashes in the overview of custom variables and in their edit window once the project is opened by CB. [EDIT: supposingly because when parsing the project file CB applies the slash to backslash conversion]
  • Slashes are converted to backslashes for internal use of the custom variables, unless they are manually edited and changed to slashes again; then these newly edited slashes are temporarily used as such  - and not converted to backslashes - until the end of the CB session. Reopening the CB project welcomes the user with all slashes converted to backslashes again. 
• Path macros like $TO_UNIX_PATH{} (pointed to http://wiki.codeblocks.org/index.php/Variable_expansion#Build_in_functions_for_path_conversion by ObFusCATed - thanks again!)
  
  • These macros appear to simply replace - in strings placed into the argument in curly brackets - slashes by backslashes and vice versa as requested regardless whether the string is a valid path or not.
  • The macros work perfectly fine - in, e.g., pre/post build steps - when applied to custom variables.
  • Macros are not expanded as part of a custom variable definition! It appears that when parsing a custom variable variables CB tries to expand expressions of the form $VAR. If $VAR is not defined, then it is expanded by a void string. This is what I saw and described above when a custom variable of the from $TO_UNIX_PATH{bla} is expanded to {bla}, since the variable $TO_UNIX_PATH does not exist (I am guessing here). (*)

Solution to my very issue:

• The variable LEX_OUTPUT is fed into a pre-compiler directive (deriving a .c file from another file) where the path defined in this custom variable is required to be a UNIX path. 
• The slash/backslash conversion must not be defined on the level of custom variables.
• Add the slash/backslash conversion to the required format to the pre-compiler string.

Potential CB enhancements:

• removing the automatic conversion of slashes to backslashes in variables in project files and upon opening a CB project
• refining the parsing of (custom) variables to allow for direct expansion of macros (see (*) above).

Can you share a minimal sample project that demonstrate this problem?

Happy to share a minimal example if still needed. Please give me a shout if so and I'll will create one.

Please note that I am living on Win10 with CB16.01.

[oBFusCATed]

Yes minimal project reproducing the problem is still preferred...

[J.]

Yes minimal project reproducing the problem is still preferred...

... here you are. I just observed that CB does insist to save slashes as backslashes in the project file (... whereas before I somehow got the impression that slashes were preserved in the .cbp files).

[stahta01]

Yes minimal project reproducing the problem is still preferred...

... here you are. I just observed that CB does insist to save slashes as backslashes in the project file (... whereas before I somehow got the impression that slashes were preserved in the .cbp files).

My experience suggest the project loading is the problem NOT the project saving; but, this is from testing done over a year ago. Tim S.

[oBFusCATed]

I'm not sure I understand what is expected to happen and what happens in your environment.
Can you explain? Provide a log?

Here is mine, running on linux:

Code

-------------- Clean: Debug in VariableExpansion (compiler: GNU GCC Compiler)---------------

Cleaned "VariableExpansion - Debug"
Running target pre-build steps
echo PATH_SLASH: ./main.c
echo PATH_BACKSLSASH: ./main.c
PATH_SLASH: ./main.c
echo TO_UNIX_PATH{(PATH_SLASH)}: ./main.c
PATH_BACKSLSASH: ./main.c
echo TO_UNIX_PATH{(PATH_BACKSLASH)}: ./main.c
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `echo TO_UNIX_PATH{(PATH_SLASH)}: ./main.c'

[J.]

I'm not sure I understand what is expected to happen and what happens in your environment.
Can you explain? Provide a log?

Sure - here is my commented log

Code

-------------- Clean: Debug in VariableExpansion (compiler: GNU GCC Compiler)---------------

Cleaned "VariableExpansion - Debug"
[ 25.0%] Running target pre-build steps

An entered slash (original version of PATH_SLASH was './main.c') saved as backslash in .cpb as shipped in my tiny example ... This is the crux of the whole thing here I believe.

Code

[ 50.0%] echo PATH_SLASH: .\main.c
PATH_SLASH: .\main.c

Effectively the same since PATH_SLASH and PATH_BACKSLASH have same values unfortunately:

Code

[ 75.0%] echo PATH_BACKSLSASH: .\main.c
PATH_BACKSLSASH: .\main.c

TO_UNIX_PATH properly converts a backslash to a slash when given as pre-build command 

Code

[100.0%] echo TO_UNIX_PATH{(PATH_SLASH)}: ./main.c
TO_UNIX_PATH(PATH_SLASH): ./main.c
echo TO_UNIX_PATH{(PATH_BACKSLASH)}: ./main.c

linux dislikes the next line apparently ... no idea why:

Code

TO_UNIX_PATH(PATH_BACKSLASH): ./main.c

The next section runs the compiler directive to compile 'main.x' with target 'main.xx' - like %.xx: %.x in make syntax - with the following compiler commands (from 'compiler_config.txt' in my .7z docarated with some comments):
NB: Typo in the definition of $PATH_BACKSLASH_MACRO: Should be '$TO_UNIX_PATH' (instead of 'PATH_TO_UNIX'). Please amend in the .cbp.

Code

echo 1 - PATH_BACKSLASH: $(PATH_BACKSLASH)                         // works - expand project variable
echo 2 - TO_UNIX_PATH(PATH_BACKSLASH): $TO_UNIX_PATH{$(PATH_BACKSLASH)}             // works - expand function (in compiler command (!)) applied to project variable
echo 3 - $PATH_BACKSLASH_MACRO                                            // fails - expand defined as project variable defined '$TO_UNIX_PATH{$PATH_BACKSLASH}' to see when functions are parsed and expanded  
echo 4 - $$(PATH_BACKSLASH_MACRO)                                       // fails - just tried because of the documentation given in the project variable definition window which appears to be confusing in the light of the result of the forth command

... back to my log again:

Code

-------------- Build: Debug in VariableExpansion (compiler: GNU GCC Compiler)---------------

[ 16.7%] mingw32-gcc.exe -Wall -g  -c C:\myDevel\myprogs\CodeBlocks\VariableExpansion\main.c -o obj\Debug\main.o

here the user-defined compiler step:

Code

[ 33.3%] echo 1 - PATH_BACKSLASH: .\main.c
echo 2 - TO_UNIX_PATH(PATH_BACKSLASH): ./main.c
echo 3 - {.\main.c
echo 4 - $(PATH_BACKSLASH_MACRO)
1 - PATH_BACKSLASH: .\main.c
2 - TO_UNIX_PATH(PATH_BACKSLASH): ./main.c
3 - 
4 - $(PATH_BACKSLASH_MACRO)
[ 50.0%] mingw32-g++.exe  -o bin\Debug\VariableExpansion.exe obj\Debug\main.o   -static-libgcc -static-libstdc++ 
Output file is bin\Debug\VariableExpansion.exe with size 31.97 KB

The test above check how/when built-in functions are expanded. However my basic question I was starting off with was is why a slash the user edits in some config interfact is saved as backslash in the .cbp xml structure? Is there any need for that? As a not so nice workaround I solved the issue by explicitly using a conversion function in a compiler directive.

NB: It appears that the functions like 'TO_UNIX_PATH' convert every slash or backslash appropriately, regardless if the argument is a proper path or not.

Sorry again for that lengthy thing here, but you asked for that. 

[oBFusCATed]

However my basic question I was starting off with was is why a slash the user edits in some config interfact is saved as backslash in the .cbp xml structure? Is there any need for that?

Because on cbp project is expected to work equally well on windows and on linux. To make this work well I think we're converting everything to unix style slashes on save and then back to the correct slash for the current OS on load.

NB: It appears that the functions like 'TO_UNIX_PATH' convert every slash or backslash appropriately, regardless if the argument is a proper path or not.

Why do you expect something different? They are simplified str_replace like functions.

Finally is there a problem and where it is? Which command fails and what is the expected output?
And please post the full log without annotations, comments or anything else.