User forums > General (but related to Code::Blocks)

Problem with '%' in editor abbreviations

<< < (2/5) > >>

thomas:
Ah, but we had that already... this will not work for environment variables.
I could do without environment variables, but I bet a good number of people will object if we break them :)


EDIT:
To clarify, we have wxGetEnv() and wxSetEnv() at our hands. So, if a variable is not known to Code::Blocks as "builtin", we can either replace it with whatever wxGetEnv() returns (empty string if not defined) or we can say "pfft... screw environment".
In reality, "empty" and "does not exist" are two different things, but we have no way of telling.

Game_Ender:
But they are almost always the same thing aren't they?  When is an environment variable set '' ever meaningful.

thomas:
Lumme if I knows! Someone might set a variable to empty when it's not needed so it never triggers an error. Just like you #define assert empty in release builds...
In any case I'm not sure if you can be so bold as to assume that empty string and unset are the same.

What if I define EXTRA_CC_OPTIONS as either "" or "-O3 -fexpensive-optimisations"? Bad example because that's done easier using project options. But let's assume those are options which aren't in the stock options.

So... I don't want to use those extra options for a certain project for some reason, and I set that variable to empty.
What happens? Code::Blocks decides that because it doesn't know that variable, it'll leave it as it is.

Result: The compiler will complain "unknown commandline option $EXTRA_CC_OPTIONS".

MortenMacFly:

--- Quote from: Game_Ender on November 13, 2006, 11:02:29 pm ---But they are almost always the same thing aren't they?  When is an environment variable set '' ever meaningful.

--- End quote ---
Well in fact it can easily happen, for example in the case of a wxWidgets configuration/version -> wxmsw$(WX_VER)wxmsx$(WX_CFG). Both of them could be empty and it makes sense if you think of using this construct on different platforms and *want* to use env. vars for that purpose - which happens surely.
With regards, Morten.

dmoore:

--- Quote from: thomas on November 13, 2006, 05:03:40 pm ---That would solve the problem in the particular example by Pecan, but not in general. The general problem persists, and cannot be solved, as people expect stuff like $($(TARGET_NAME)_OUTPUT_FILE) to work. This only works because macro replacement (errornously) runs recursively. As long as this is true, we cannot escape the control chars :(

--- End quote ---

this is only a problem if you recurse on your escape character, which you shouldn't. why not allow a user-definable escape character (some punctuation character that is not in the set of chars that get recursed and, ideally, not in the c/c++ language). you could then convert all of your escapes to something safe for the recursed regex and then convert them to flat text afterwards

BTW, according to the wxWidgets docs:


--- Quote ---wxGetEnv

bool wxGetEnv(const wxString& var, wxString *value)

Returns the current value of the environment variable var in value. value may be NULL if you just want to know if the variable exists and are not interested in its value.

Returns true if the variable exists, false otherwise.

--- End quote ---

is this broken?

Navigation

[0] Message Index

[#] Next page

[*] Previous page