Code::Blocks Forums
User forums => General (but related to Code::Blocks) => Topic started by: Dmitri on November 10, 2017, 04:25:26 pm
-
For some reason C::B behaves like this. It should add quotes for any paths (output, intermediate dir, source and output files, ...) in any case.
-
Why should it add quotation marks in a scenario when they are not required for proper functionality?
-
They are actually required "for proper functionality". Take this as a simple rule.
What if you have an environment variable in your path, which contains a string with spaces?
-
We will expand the variable and then we'll decide if we need to add quotes or not, I guess.
This discussion is pointless if you don't show concrete examples where cb produces wrong paths.
And keep in mind that sometimes adding quotes could confuse programs which doesn't expect them, so it is not as easy as always-put-quotes around paths...
-
Here's a concrete example for you:
1. Create a folder on your desktop, and put spaces into its name. Example: "fol der".
2. Create a C::B project in this folder.
3. Change output path to $(PROJECT_DIR)\output
4. Try to compile your project with mingw-64 compiler.
And we're not talking about abstract programs, it's Code::Blocks and mingw only.
-
If you manually put quotation marks around your output path, does it work?
-
No, it won't work.
-
I would think that means one of two things:
1. If there are quotes around it, perhaps C::B doesn't expand the $(PROJECT_DIR) variable?
2. C::B putting quotes around it wouldn't have worked anyway as one of the other parts of the toolchain won't support this path as oBFusCATed suggested. You'd need to change the project path to one without spaces.
-
Which part of toolchain will cause problems?
Also, did you ever work with mingw compiler?
-
I use MinGW (first party MinGW, not the third party MinGW-64) exclusively, but then again I don't put spaces in my project paths because I don't want to have to troubleshoot any problems that may come of it. If you remove the $(PROJECT_DIR) variable and explicitly define the path with quotation marks, does it work? If not, then this isn't a problem C::B can solve because the compiler isn't allowing you to use the path containing spaces.
-
Mingw can work with parameters that are embraced with quotation marks, that's not a problem with compiler.
Can anyone from developers check if there's a real problem exists with expanding variables in such cases?
I use MinGW (first party MinGW, not the third party MinGW-64) exclusively
Isn't it outdated? I know it was not updated with C++14.
-
I can't immediately tell that MinGW supports C++14.