User forums > Help

build codeblocks src

<< < (2/3) > >>

Jenna:

--- Quote from: thomas on April 20, 2008, 08:04:07 pm ---Hmm... and I can even reproduce it manually on the commandline.

So it seems that getopt (or whatever parses gcc's command line) interpretes the \" as an escaped quote. :(

That's unfortunate, because it imposes a serious limit on what constitutes a valid pathname, and we cannot do without the quotes.

--- End quote ---

Isn't it possible to remove a trailing backslash if C::B adds the quotes ?
Or to add a space before the quote?

All that will of course only work if the user does not add the quotes manually.

thomas:
Hmm yes, that would of course work, but it's not really good either :(

I hate it when a program tries to be smarter than me and modifies the paths or names that I enter, that's no good thing. For example, someone might have all paths end in a backslash on purpose because he wants to concatenate them... or whatever (something like $path$file).
The problem with computers being "smart" and tampering with the things you enter is that computers are never really smart, so for every case you fix, there's one case where it breaks something else.
I'm not sure what is best to do :(

It's like when I come from the supermarket and drive up the little hill in front of my house. As there is a gentle slope going down for about 1.5 kilometers followed by a 100 m steep hill, the hybrid engine will have collected enough energy so I can drive the entire distance without spending a single drop of fuel. However, if I only push the accelerator a bit too strong, the computer in all its smartness figures that I'm going on a mountain rallye, so it fires up the combustion engine for "max power". If the computer was really smart, it would realize that I'm 100 meters from home, and that it really doesn't matter whether I get there 0.75 seconds earlier or not.

thomas:
Maybe we could double trailing backslashes...?
Only Windows uses backslashes, and runs of backslashes are treated as one, by definition.

If some program does not interprete quoted chars, it will be ok.
If \\ is interpreted as a quoted char, it translates to \, and won't touch the quote char... which again, is ok.

Jenna:
Good idea !

I just tried the following patch on my W2K kvm-box and it seems to work:


--- Code: ---Index: src/sdk/globals.cpp
===================================================================
--- src/sdk/globals.cpp (revision 5010)
+++ src/sdk/globals.cpp (working copy)
@@ -184,7 +184,11 @@
  bool hasSpace = str.Find(_T(' ')) != -1;
  bool hasParen = !platform::windows && (str.Find(_T('(')) != -1 || str.Find(_T(')')) != -1);
     if (!str.IsEmpty() && str.GetChar(0) != _T('"') && (hasSpace || hasParen))
+    {
+        if (str.Last() == _T('\\'))
+            str+=_T('\\');
         str = wxString(_T("\"")) + str + _T("\"");
+    }
 }
 
 wxString EscapeSpaces(const wxString& str)

--- End code ---

I only compiled a smalll test project with one additional include dir that includes spaces, but everything works fine.

Brentoids:
It is definitely because of the backslashes.  i moved MinGW to a path without spaces and changed the references in:

Settings\Compiler and debugger\ [tab] Search directories\ [tab] Compiler
Settings\Compiler and debugger\ [tab] Search directories\ [tab] Linker
Settings\Compiler and debugger\ [tab] Search directories\ [tab] Resource compiler
Settings\Compiler and debugger\ [tab] Toolchain executables\ Compiler's installation directory

and then the build proceeded as normal.  I then hit,

E:/Coding/Lib/wxWidgets-2.8.7/include/wx/platform.h:196:22: wx/setup.h: No such file or directory

errors, but I believe I can fix these after I read http://wiki.codeblocks.org/index.php?title=Nightly_Cookbook.  I didn't have the time to work on this today, but thought I'd drop an update.

Navigation

[0] Message Index

[#] Next page

[*] Previous page