Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

backtick support

(1/1)

dmoore:
While helping epsilon_da setup a wizard for GTK, we discovered the "other options" (including backticks) don't receive the macro substitution treatment that other build settings receive.

This patch rectifies that:


--- Code: ---Index: src/sdk/compilercommandgenerator.cpp
===================================================================
--- src/sdk/compilercommandgenerator.cpp (revision 5535)
+++ src/sdk/compilercommandgenerator.cpp (working copy)
@@ -697,7 +697,11 @@
     // compiler options
     result << GetStringFromArray(compiler->GetCompilerOptions(), _T(' ')) << _T(" ");

-    wxString bt = ExpandBackticks(result);
+    Manager::Get()->GetMacrosManager()->ReplaceMacros(result, target);
+//    QuoteStringIfNeeded(result); //CAUSED PROBLEMS
+    FixPathSeparators(compiler, result);
+
+ wxString bt = ExpandBackticks(result);
     SearchDirsFromBackticks(compiler, target, bt);

     // add in array
@@ -724,7 +728,11 @@
     // linker options
     result << GetStringFromArray(compiler->GetLinkerOptions(), _T(' '));

-    wxString bt = ExpandBackticks(result);
+    Manager::Get()->GetMacrosManager()->ReplaceMacros(result, target);
+//    QuoteStringIfNeeded(result); //CAUSES PROBS
+    FixPathSeparators(compiler, result);
+
+ wxString bt = ExpandBackticks(result);
     SearchDirsFromBackticks(compiler, target, bt);

     // add in array

--- End code ---

Reason to include this patch: Can help to make maintaining project options simpler (e.g. use a global variable $(#GTK_PKG_CONFIG) to point to the gtk pkg-config utility on windows so that projects can supply portable backticks like `$(#GTK_PKG_CONFIG) gtk+-2.0 --cflags`).

Reason *NOT* to include this patch: You tell me...

MortenMacFly:

--- Quote from: dmoore on April 13, 2009, 10:10:45 pm ---Reason *NOT* to include this patch: You tell me...

--- End quote ---
I don't see any... my projects with such functionality still work fine. Other devs?!

Jenna:
Nothing against the patch in general.

But one question/objection: why do you call FixPathSeperator here ?

Think of this case:
The compiler used has forceFwdSlashes set to true, and the user wants to define a string at the commandline like:

--- Code: ----DTEST="\"The String\""
--- End code ---

in build options we have to write
--- Code: ---TEST="\\"The String\\""
--- End code ---
in defines tab.

The string will be "fixed" to
--- Code: ----DTEST="//"The String//""
--- End code ---

what leads to an error at compile-time:
--- Code: ---g++: String//: No such file or directory
--- End code ---

dmoore:
thanks for responding guys.


--- Quote from: jens on April 14, 2009, 12:33:31 pm ---Nothing against the patch in general.

But one question/objection: why do you call FixPathSeperator here ?

--- End quote ---

copy and paste from how its done else where in the code - didn't think about it at the time, your example illustrates the problem. the patch just got simpler. :)

I'm struggling to think of any cases where the macro substitution itself could clash with legitimate compiler or linker options.

Navigation

[0] Message Index