Custom variables ssetup in the compiler not get applied

[MortenMacFly]

Dear all,

I've setup two custom (not global!) variables in the GCC compiler setup to setup additional path's for the compiler/linker. As of today they are not applied when I try to compile a project that uses these variables in the compiler/linker step. I've seen that there was a change in codecompletion/nativeparser.cpp that could cause the error but I'm not sure because imho this has nothing to do with codecompletion...?! Any help is appreciated.

Morten.

[thomas]

I am already looking into this, it must have been me who broke it. Though I think it is rather something in MacrosManager than the changes in code completion (the latter is not related to that).

[thomas]

Now that was an interesting bug   Fixed.

[MortenMacFly]

Now that was an interesting bug   Fixed.

...are you sure? Because with the current version (1534) out of the repository it still does not work for me. I wish I could try the old version of "codecompletion/nativeparser.cpp" but I'm fighting with svn to give me this revision only for this file. Although it seems to be strange but there are changes related to custom compiler variable expansion... Thanks for your quick (!) reply and help anyway!

Morten.

[rickg22]

codecompletion has *NOTHING* to do with compiler variables... these belong to the compile plugin / macrosmanager.

[MortenMacFly]

codecompletion has *NOTHING* to do with compiler variables... these belong to the compile plugin / macrosmanager.

Alright, I trust you. I was just curious because look at the diff: The following lines are commented (to be removed?) in the current revision compared to the previous one:

Code

//    // apply compiler global vars
//        compiler->GetCustomVars().ApplyVarsToEnvironment();
//    project->GetCustomVars().ApplyVarsToEnvironment();
//            target->GetCustomVars().ApplyVarsToEnvironment();

Morten.

[rickg22]

This is because custom vars are replaced now without getting applied to the environment.

[MortenMacFly]

This is because custom vars are replaced now without getting applied to the environment.

Alright, I got the point. Thanks, Rick.

Morten.

[thomas]

Yes, I am sure I fixed it   I tested a dozen times.
But... with this fix, I broke something else (and which I did not test  *cough*). Global user vars currently don't work.

Seems it is not my day today.

[rickg22]

don't worry, we all have had our days *pat pat*

[rickg22]

Morten: Thomas is telling me that he only added debug output and suddenly it works again. Can you try to reproduce the exact steps you took to compile? Were you rebuilding, building all, workspace, only one target, or what? What exact variables were you replacing, and what values did they have? What project were you trying to compile? (CB? what revision?)

[MortenMacFly]

Morten: Thomas is telling me that he only added debug output and suddenly it works again. Can you try to reproduce the exact steps you took to compile? Were you rebuilding, building all, workspace, only one target, or what? What exact variables were you replacing, and what values did they have? What project were you trying to compile? (CB? what revision?)

The time you were writing this I was already asleep... I hope you guys had some sleep, too. :shock:
I can confirm that it is working by now. I've done another update today in the morning where the only file that was updated was macrosmanager.cpp. Doing a "build all" (of the C::B workspace, NewBuild) with this updated file everything is working.
However: With the interim-build of yesterday evening I was refering to I could have had also the problem as described in http://forums.codeblocks.org/index.php?topic=1674.0 since I am using global variables, too. I could imagine that I was faced this error instead of custom variables one... The build log is so big and the result would have been the same (a linker error). Sorry for the confusion.

Morten.
P.S.: Because you were asking: I have setup a path to a special lib in the compiler custom variables properties: "RAPID_LIBS=D:\Devel\RAPID\libs". This path I have setup in the directory settings for the linker of my project: $(RAPID_LIBS), that's it. The value was still assigned in the compiler setup but the compiler/linker output showed an empty "-L" entry in the log. Maybe for the future a testcase-(dummy-)project could be setup that depends on 1.) a global variable, 2.) a custom variable setup in the compiler settings, 3.) a custom variable setup in the project settings...

[MortenMacFly]

Dear all,
I am sorry to stress this topic again, but by now I believe it does unfortunately not work (SVN 1562). I am using as an output path "$(MY_LIBS)\mylib.a". The MY_LIBS environment variable has been setup in the compiler settings because if I use another compiler I would like to use other libs (compiled with this compiler, e.g. MSVC). So I thought setting up the environment variable in the compiler settings would do what I want. Hence the "MY_LIBS" variable is not resolved. That it was working in my previous post had a simple reason: All the libs were created in the root of the target drive (notice the "\" in the settings). Therefore they were found and linked.
To sum up: The variables setup in the project properties are resolved but not the ones from the compiler setup.
Furthermore I have another question. If a variable to a include-/lib-path is empty the command-line passed to the compiler will include empty "-I" and "-L" statements. Wouldn't it make sense to remove those from the command line? I'm no sure but I believe some compilers will struggle with e.g. "-L -LAnotherDir" because the path that is tried to be included will then be "-LAnotherDir" which does certainly not exist.

Of course it may also be my fault - so I am open for discussions.

Morten.

[thomas]

Something that is still being worked on is per-target variables. These indeed still have a problem.

[MortenMacFly]

Something that is still being worked on is per-target variables. These indeed still have a problem.

Do you really mean per-target and not per-project? If so, then it sounds like an interesting new feature!
...just to make very sure: The per-project is working for me, what is not working is per-compiler. I haven't used/seen the per-target variables so far but that would certainly be a nice option, though.
However: If there's ongoing work on that topic then I understand and will just be patient. By now I've changed my projects to use per-project variables as a work-around. So it's not a big deal for me. I'll give it a try sometimes later and complain if it's still not working. (...hoping you don't mind... :lol:)

Morten.

[MortenMacFly]

Do you really mean per-target and not per-project? If so, then it sounds like an interesting new feature!

...sorry, I have been an idiot. Of course there is the possibility for per-project and per-target variables. I got that part wrong... The other things I mentioned still apply.
Morten.

[tiwag]

i updated today to SVN rev 1578 and found, that it is not possible
to use more than one custom variable for a single expression any longer !

i have set-up my project templates with custum variables as follows:

Code

WXVER = 26
WXREL = 1
WXVERREL = $(WXVER)$(WXREL)
WXDIR = d:\wx$(WXVERRREL)
WXDLL = wxmsw$(WXVER)
...

all my projects are broken now, because the WXVERREL macro expands to ""

[takeshimiya]

Yep, you must know, these days macro expansion brokes very often

[tiwag]

Yep, you must know, these days macro expansion brokes very often

[edit append]
i just tested, that with my previous SVN build rev 1565 these combined macros are getting expanded properly.
hth