User forums > Using Code::Blocks

custom variable string: loading .cbp converts slash to backslash

<< < (2/3) > >>

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

J.:

--- Quote from: oBFusCATed on April 15, 2017, 11:50:59 am ---Yes minimal project reproducing the problem is still preferred...

--- End quote ---
... 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:

--- Quote from: J. on April 17, 2017, 11:29:19 am ---
--- Quote from: oBFusCATed on April 15, 2017, 11:50:59 am ---Yes minimal project reproducing the problem is still preferred...

--- End quote ---
... 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).

--- End quote ---

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'

--- End code ---

J.:

--- Quote from: oBFusCATed on April 20, 2017, 07:59:07 pm ---I'm not sure I understand what is expected to happen and what happens in your environment.
Can you explain? Provide a log?

--- End quote ---

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

--- End code ---
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

--- End code ---
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

--- End code ---
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

--- End code ---
linux dislikes the next line apparently ... no idea why:

--- Code: ---TO_UNIX_PATH(PATH_BACKSLASH): ./main.c

--- End code ---

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

--- End code ---

... 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

--- End code ---
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

--- End code ---

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.  ::)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version