Author Topic: EnvVars Plugin and PATH  (Read 41301 times)

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
EnvVars Plugin and PATH
« on: February 09, 2012, 10:34:16 pm »
Hi there,
  I noticed a strange behavior when setting PATH EnvVar with help of the EnvVars Plugin.

I am doing a simple "hello world" kind of program using Allegro 5.0.5 Libray, and set up a very simple project with a single "main.c" and 4 targets (Debug and Release, both and dinamically statically linked to the library).

Compiling and linking is no problem and each target built correctly (and works :) )

Still, the dll's to with I dynamically link aren't in the executable path nor in Win7 %PATH%, so I defined a "liballeg" set of a single Envvar (also set to be used in the EnVars tab of project properties) "PATH" with value "%PATH%;pathtoliballegro;pathto mingwruntime libraries" (see attached pictures).

This allows me to run the dynamically linked executables without actually changing PATH in the windows environment

Well, everything works fine until I press "build" (EVEN if the current target is up to date and nothig has tobe done), then the dynamically linked executables fails to start up and the OS is giving the "unable to find dll" error message.

If I go to the envVars panel and press "set now" or I go in the envVars tab in project properties and set again the (same) set of envvars, then the executables are able to find their dll...

This does not seem the intended behavior, but maybe I am doing something wrog so I am asking if this could be a bug or is only my fault.

I am using the latest official release of C::B (10.05) over Win7, and MinGW 4.5.2 toolchain (NOT the one bundled in C::B).

Images




Thanks for any help


Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: EnvVars Plugin and PATH
« Reply #1 on: February 10, 2012, 02:37:45 am »
I have not used the EnvVars plugin before, so I could be completely wrong, but I believe what it sets are global/per-project variables (not variables in the system environment).

Something you could try is to have add your bin folder (C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin) to both the compiler and the linker search directories of your project.

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #2 on: February 10, 2012, 08:57:19 am »
Since I am in the office, I may only be able to try this later, but I'm under the impression that it will not work...and exe looking for an external launches an OS call so I guess that the OS EnvVars are involved in the process, not compiler nor linker.

Besides, C::B correctly detects that PATH is a system EnvVar and explicitly tells that whichever value I set it will be done recursively (meaning, I guess, that the current PATH will have those value appended, not substituted).

Setting PATH in Win7 of course does the trick, but I'd like to understand if the EnvVars plugnin can be used in this way or not.

EDIT: having gone (again) through the Wiki you linked me, seems that the envvvars plugin is specifically designed to dabble with system EnvVars, as I deducted reading here
« Last Edit: February 10, 2012, 09:05:35 am by pkrcel »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: EnvVars Plugin and PATH
« Reply #3 on: February 10, 2012, 08:58:30 am »
Alpha: You are wrong here. It sets system env variables and at least on linux it works as expected.

pkrcel: Can you try with the latest nightly build?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #4 on: February 10, 2012, 09:06:16 am »
pkrcel: Can you try with the latest nightly build?
In addition: Can you enable the ennvars "debug log" (Settings -> Environment -> Envvars) and C::B's "debug log" (by starting C::NB with the command line option --debug-log) and post what the plugin does here? It's written to the debug log then.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #5 on: February 10, 2012, 09:27:37 am »
I've tried with the SVN7671 and the behavior is exaclty the same.


I'm about to retrieve and post the logs.


EDIT:

Attached the debug log.  :)


EDIT2:
for completeness, the log is refered to the following actions:

- launch C::B
- selected latest project (AllegroTUT1)
- launch the "debug_Dyn" target -> "it's all good"
- press "build" -->  "nothing to be done"
- re-launch the same target -> "cannot find DLL"



« Last Edit: February 10, 2012, 09:40:11 am by pkrcel »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #6 on: February 10, 2012, 09:47:27 am »
Attached the debug log.  :)
OK, If I look at this:
EnvVars: Obtained 'liballeg' as active envvar set from config.
EnvVars: Active envvar set is 'liballeg', config path '/sets/liballeg'.
EnvVars: Searching for envvars in path '/sets/liballeg'.
EnvVars: Read 1/1 envvars in path '/sets/liballeg'.
EnvVars: Trying to set environment variable 'PATH' to value 'C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ZipGenius 6\;C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin;C:\MingW\bin'...
EnvVars: 1/1 envvars applied within C::B focus.

EnvVars: Obtained 'liballeg' as active envvar set from config.
EnvVars: Discarding envvars set 'liballeg'.
EnvVars: Obtained 'liballeg' as active envvar set from config.
EnvVars: Active envvar set is 'liballeg', config path '/sets/liballeg'.
EnvVars: Searching for envvars in path '/sets/liballeg'.
EnvVars: Read 1/1 envvars in path '/sets/liballeg'.
EnvVars: 1/1 envvars discarded within C::B focus.
EnvVars: Setting up envvars set 'liballeg' for activated project.
EnvVars: Active envvar set is 'liballeg', config path '/sets/liballeg'.
EnvVars: Searching for envvars in path '/sets/liballeg'.
EnvVars: Read 1/1 envvars in path '/sets/liballeg'.
EnvVars: Trying to set environment variable 'PATH' to value ';C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin;C:\MingW\bin'...
EnvVars: 1/1 envvars applied within C::B focus.

EnvVars: Obtained 'liballeg' as active envvar set from config.
EnvVars: Found 2 envvar sets in config.
EnvVars: Found 2 envvar sets in config.
EnvVars: Setup 2/2 envvar sets from config.
EnvVars: Active envvar set is 'liballeg' at index 1, config path '/sets/liballeg'.
EnvVars: Searching for envvars in path '/sets/liballeg'.
EnvVars: Read 1/1 envvars in path '/sets/liballeg'.
EnvVars: Trying to set environment variable 'PATH' to value ';C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin;C:\MingW\bin;C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin;C:\MingW\bin'...
EnvVars: 1/1 envvars applied within C::B focus.

I guess I know/see what happens... This might indeed be a bug due to discarding nested envvars. I'll look into it...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #7 on: February 10, 2012, 09:52:34 am »
Good, I'll stay tuned...and thanks for all this C::B goodness anyway :)



Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #8 on: February 10, 2012, 12:49:11 pm »
Good, I'll stay tuned...and thanks for all this C::B goodness anyway :)
Should be fixed in trunk. Feel free to try...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #9 on: February 10, 2012, 01:26:40 pm »
That was FAST!  ;D

Since I'm not all that accustomed with SVN/git and the like...you mean I shall retrieve all TRUNK and build Code::Blocks or I can do only the plugin?



Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #10 on: February 10, 2012, 01:35:32 pm »
Since I'm not all that accustomed with SVN/git and the like...you mean I shall retrieve all TRUNK and build Code::Blocks or I can do only the plugin?
...depends: If you link against a nightly, a checkout / build of the envvars plugin will be enough. If you are using an old version of C::B you'll have to wait for the next nightly. But I am sure it won't take long until then...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #11 on: February 10, 2012, 01:42:45 pm »
Ok thanks, I thought to checkout into the latest nightly I installed for this trial....will try and see, otherwise I will lazily wait for anightly :P


Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: EnvVars Plugin and PATH
« Reply #12 on: February 10, 2012, 10:44:41 pm »
EDIT: having gone (again) through the Wiki you linked me, seems that the envvvars plugin is specifically designed to dabble with system EnvVars, as I deducted reading here
Alpha: You are wrong here. It sets system env variables and at least on linux it works as expected.
Apologies for the incorrect information... it looks like I have mislead myself based on a previous edit I did to the plugin's page :-[.  (I have now changed it to be more accurate.)

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #13 on: February 11, 2012, 01:17:21 am »
No need to apologize Alpha, at least to my concern :)

In the meantime I went full league and built C::B from sources (SVN 7787) , with all the contrib plugins....unfortunately it has the same behavior as 10.05, attached you can find the debug-log. ..if that is of any help.

Now that I've a fully working build environment for C::B I should be able to check faster ;D


Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #14 on: February 11, 2012, 06:12:26 am »
attached you can find the debug-log. ..if that is of any help.
Hmmm, I don't see what could go wrong now. Can you strip down you project to a minimalistic example and provide me with exact steps what you do to achieve this "error"? Also, please attach your (zipped) default.conf file - at least the ennvars section, starting with:
Code
	<envvars>
<sets>
<default>
[...]
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #15 on: February 11, 2012, 10:54:15 am »
The project is already minimalistic, is a VERY simple allegro tutorial :)

Attached is the project zip file, I haven't stripped any info (except objs and exes!), and there is also the default.conf file.

The problem of course occurs only wih the dyanmically linked exes (targets Release_dyn and Debug_dyn).

To achieve this "error":

 - select a Dyn target (either one), and press "run"....usually the first time all goes fine and you shoul receive a "it's all good" messagebox
 - press "build", you should get a "target up to date" message in the build log window.
 - press "run" again, now you should get the "cannot find allegro monolith dll" error message.

Obviously enuff, the allegro monolith dll should not reside in your PATH or along the Dyn exes..this iis what I am using the envVars plugin for

I am running Win7 and nothing chanfges if I run C::B in admininstrator mode....
« Last Edit: February 11, 2012, 11:00:40 am by pkrcel »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #16 on: February 11, 2012, 11:30:26 am »
Attached is the project zip file, I haven't stripped any info (except objs and exes!), and there is also the default.conf file.
You do have one, trust me, you find it either under ~/.codeblocks (Linux) or in %APPDATA%\codeblocks on Windows. Notice that you don't need to provide the whole file, just the envvars section (you can open it with a XML capable editor like Code::Blocks). But remember DO NOT MODIFY THIS FILE!!! Just extract the content requested to a new file.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #17 on: February 11, 2012, 11:44:47 am »
Of course I have that file, I thought I have included it into the previous ZIP.

Here is the ennvars section anyway:

Quote
   <envvars>
      <sets>
         <default />
         <liballeg>
            <ENVVAR0>
               <str>
                  <![CDATA[1|PATH|%PATH%;C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin;C:\MingW\bin]]>
               </str>
            </ENVVAR0>
         </liballeg>
      </sets>
      <ACTIVE_SET>
         <str>
            <![CDATA[liballeg]]>
         </str>
      </ACTIVE_SET>
      <DEBUG_LOG bool="1" />
   </envvars>

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #18 on: February 11, 2012, 02:06:45 pm »
- select a Dyn target (either one), and press "run"....usually the first time all goes fine and you shoul receive a "it's all good" messagebox
 - press "build", you should get a "target up to date" message in the build log window.
 - press "run" again, now you should get the "cannot find allegro monolith dll" error message.
Works fine here. However, your project settings are really screwed. you hard-code path, path's to libs and use full path's for the names of the libs. So I had to completely modify what you did to use relative path's and (compiler / linker) include path's.

Maybe that's the reason it works for me, but I hit compile/run several times, it always worked. I even switched targets in between - worked, too. (Win7, non-admin).

Maybe you should try to setup your project in a better way: Never use path's for libs to link against: Only use lib names and let the linker know where to search for the libs by providing the linker include path's accordingly. The same applies to the compiler.

Also, I saw you link against DLL's. While this might be correct and work, on MinGW you usually line against an import library for DLL's. So, just "try again" please... ;-)

And btw: You should never need to run C::B as an admin. If you do, something is wrong on your side. C::B does not require admin rights. It would be really bad if it would.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #19 on: February 11, 2012, 10:47:06 pm »
Okay Morten, I am following your instructions...but I am unable to make it work, I always experience the same problem. :(

- I cleaned up the search paths for linker and compilier defining a global compiler/linker varible "liballeg" that points to the location in which lib allegro is installed and use variable expansion such as $(#liballeg.include) and $(#liballeg.lib)

I've put the library names in linker settings as libgdiplus, trimming out the leading path (man, that was UGLY! this happen when you follow certain instructions without using your brain  :-X, I'm truly ashamed)

I now link against the library "liballegro-5.0.5-monolith-md" instead of the DLL itself (even thou the dll is compiled with MingW...that's why it worked before I guess: ref).

Compiling and linking works fine (no, it works BETTER ;D) as before...but I run into the same problem with PATH, I relativized it to $(#liballeg.obj) having defined obj ans the \bin subfolder but behavior is exactly the same as before.

I also deleted the "liballeg" set of variables and defined PATH in the "default" set but again the behavior is the same.

Question: is there a way to see the value of PATH at any time inside C::B focus?








Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: EnvVars Plugin and PATH
« Reply #20 on: February 12, 2012, 12:01:11 am »
Question: is there a way to see the value of PATH at any time inside C::B focus?

I have used "CMD /C echo %PATH%" without the quotes in the post build step; note it can lock up the build and requires the abort button to be pressed to stop it. I added the "/C" option and it no longer locked up for me.

Tim S.
« Last Edit: February 12, 2012, 12:04:02 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #21 on: February 12, 2012, 01:27:47 am »
Thanks, this was indirectly useful...I defined a tools+ (named pathexpl) that invokes "cmd /c path" redirected to the C::B console.

If I call this upon launch of C::B I obtain the following:

Quote
PATH=C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Fi
les\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Fil
es\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\Syste
m32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Comm
on Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Share
d\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\
;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program
 Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\
Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\T
ortoiseSVN\bin;C:\Mingw32\bin;C:\Users\Provasi\_user\Coding\Libraries\allegro-5.
0.5-mingw-4.5.2\bin

Process returned 0 (0x0)   execution time : 0.033 s
Press any key to continue.

and running Debug_Dyn target is (of course) successful.

I then hit build (and get the "target up to date" message)

and again invoke pathexpl, and obtain:

Quote
PATH=C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Fi
les\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Fil
es\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\Syste
m32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Comm
on Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Share
d\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\
;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program
 Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\
Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\T
ortoiseSVN\bin;C:\Mingw32\bin

Process returned 0 (0x0)   execution time : 0.023 s
Press any key to continue.


and, quite expected, there is no longer the path to "$(#liballeg)\bin" in the end, so hitting run returns the "cannot find allegro dll" error.

I do not know why of course.... ???

Going to the Envvars panel in Environment settigns and pressing "set now", then

Quote
PATH=C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Fi
les\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Fil
es\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\Syste
m32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Comm
on Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Share
d\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\
;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program
 Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\
Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\T
ortoiseSVN\bin;C:\Mingw32\bin;C:\Users\Provasi\_user\Coding\Libraries\allegro-5.
0.5-mingw-4.5.2\bin

Process returned 0 (0x0)   execution time : 0.021 s
Press any key to continue.

Any ideas?   ???

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #22 on: February 12, 2012, 10:31:06 am »
Any ideas?   ???
OK, I think I know why and this is not "nice". You said you compile C::B yourself. Can you do me a favour and search for the following in the compiler plugins's compilergcc.cpp file (should be in CompilerGCC::SetupEnvironment()):
Code
    if (!m_OriginalPath.IsEmpty())
        wxSetEnv(_T("PATH"), m_OriginalPath);
...and replace it with:
Code
    if (!m_OriginalPath.IsEmpty())
    {
        Manager::Get()->GetLogManager()->DebugLog(_T("Setting up compiler PATH environment..."));
        wxSetEnv(_T("PATH"), m_OriginalPath);
    }
Then search for (should be in CompilerGCC::SetEnvironmentForCompiler()):
Code
        envPath = envPath + GetStringFromArray(envPathArr, path_sep, false);
        wxSetEnv(_T("PATH"), envPath);
...and replace it with:
Code
        envPath = envPath + GetStringFromArray(envPathArr, path_sep, false);
        Manager::Get()->GetLogManager()->DebugLog(_T("Updating compiler PATH environment..."));
        wxSetEnv(_T("PATH"), envPath);
Then compile, run C::B with the debug console and inspect when C::B sets the PATH from the compiler and from the Envvars plugin respectively. I have the feeling that the compiler "resets" the PATH when you hit compile.

If that is the case, I need to think about a new concept for this (this applies to the PATH environment only!!!).

In the meantime, you have these work-arounds:
1.) In the project options, setup the "execution working dir" for your targets to the allegro bin folder.
2.) In the compiler setup, append the path to the allegro bin folder under "additional paths".
3.) Depending on your platform, adjust the PATH environment variable "globally" (per user).

EDIT: Oh and for testing, you can use a simple "command only" project as this (MyCmd.cbp):
Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
<FileVersion major="1" minor="6" />
<Project>
<Option title="MyCmd" />
<Option compiler="gcc" />
<Build>
<Target title="default">
<Option type="4" />
<Option compiler="gcc" />
<ExtraCommands>
<Add before="echo &lt;PRE_BUILD&gt;" />
<Add before="echo %PATH%" />
<Add before="echo &lt;/PRE_BUILD&gt;" />
<Add after="echo &lt;POST_BUILD&gt;" />
<Add after="echo %PATH%" />
<Add after="echo &lt;/POST_BUILD&gt;" />
<Mode after="always" />
</ExtraCommands>
</Target>
</Build>
<Extensions>
<envvars set="dummy" />
</Extensions>
</Project>
</CodeBlocks_project_file>
« Last Edit: February 12, 2012, 10:36:50 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline pkrcel

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: EnvVars Plugin and PATH
« Reply #23 on: February 12, 2012, 10:58:14 am »
Of course I sticked for (3)for the time being. ;D

Anyway, I did as per your request, just rebuilt C::B and attached you can find the debug log for the same steps as before.

I think the additions you made me push in ended up in this:

Quote

[....]
EnvVars: Searching for envvars in path '/sets/default'.
EnvVars: Read 1/1 envvars in path '/sets/default'.
EnvVars: Trying to set environment variable 'PATH' to value 'C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\TortoiseSVN\bin;C:\Mingw32\bin;C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin'...
EnvVars: 1/1 envvars applied within C::B focus.
Passing list of files to batch-parser.
Header to parse with priority: 'C:\MinGW\lib\gcc\mingw32\4.6.1\include\c++\cstddef'
Header to parse with priority: 'C:\MinGW\include\w32api.h'
Add 2 priority parsing file(s) for project 'AllegText'...
Added 1 file(s) for project 'AllegText' to batch-parser...
Create new parser for project 'AllegText'
Updating class browser...
Class browser updated.
Starting batch parsing for project 'AllegText'...
Project 'AllegText' parsing stage done!
Project 'AllegText' parsing stage done (53 total parsed files, 1657 tokens in 0 minute(s), 0.589 seconds).
Updating class browser...
Class browser updated.
Setting up compiler PATH environment...
Updating compiler PATH environment...
Scanned 0 files for #includes, cache used 0, cache updated 0
Scanned 0 files for #includes, cache used 0, cache updated 0
Scanned 0 files for #includes, cache used 47, cache updated 0
Scanned 0 files for #includes, cache used 0, cache updated 0
Scanned 0 files for #includes, cache used 0, cache updated 0
Scanned 0 files for #includes, cache used 0, cache updated 0
Setting up compiler PATH environment...
Updating compiler PATH environment...
Scanned 0 files for #includes, cache used 0, cache updated 0
Setting up compiler PATH environment...
Updating compiler PATH environment...

Scanned 0 files for #includes, cache used 0, cache updated 0


EDIT
using your testbed I get this in the build log

Quote
Running target pre-build steps
cmd /c echo PRE_BUILD
PRE_BUILD
cmd /c echo C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\TortoiseSVN\bin;C:\Mingw32\bin
C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\TortoiseSVN\bin;C:\Mingw32\bin

-------------- Build: default in MyCmd ---------------

Linking stage skipped (build target has no object files to link)
Running target post-build steps
cmd /c echo POST_BUILD
POST_BUILD
cmd /c echo C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\TortoiseSVN\bin;C:\Mingw32\bin
C:\MinGW\bin;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared\;c:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared\;c:\Program Files (x86)\Roxio\OEM\AudioCore\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ZipGenius 6\;C:\Program Files\SlikSvn\bin;C:\Program Files\TortoiseSVN\bin;C:\Mingw32\bin
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)

[attachment deleted by admin]
« Last Edit: February 12, 2012, 11:25:54 am by pkrcel »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #24 on: February 12, 2012, 12:32:19 pm »
I think the additions you made me push in ended up in this:
So, it seems I was right: Setting up the PATH envvar using the EnvVars plugin interferes with the compiler plugin that uses the PATH envvar, too for settings up additional path's as setup by the user in the compiler's tool chain settings. Unfortunately it uses a cached PATH anvvar - so the one before the EnvVars plugin updated it. Interesting to see: It depends on the priority of the plugin, so if you were able to setup a higher priority for the EnvVars plugin it would probably work...

Notice that this only applies to the PATH and probably LD_LIBRARY_PATH envvar, every other nested envvar should work just fine.

I see two solutions:
1.) Update the EnvVars plugin so it gets activated every time a file is compiled (which is after the compiler sets the PATH envvar) -> not nice, because of many calls to update the envvar when compiling large projects, OR
2.) Update the compiler plugin so it always caches the *current* PATH envvar when updating/restoring it.

I think solution 2.) is the better one, however, I don't know if it doesn't have side effects... ???

Any thoughts by any of the other devs?
« Last Edit: February 12, 2012, 12:33:57 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: EnvVars Plugin and PATH
« Reply #25 on: February 12, 2012, 02:28:21 pm »
I tend to 2., but have to look into it.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: EnvVars Plugin and PATH
« Reply #26 on: February 13, 2012, 12:39:36 am »
+1 for 2
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: EnvVars Plugin and PATH
« Reply #27 on: February 13, 2012, 09:54:18 am »
Actually we call SetupEnvironment, which does nothing but restire the cached PATH, if it is cached, or cache the PATH if the cache is empty.
And it warns if the PATH variable is empty.

SetupEnvironmant()
calls SetEnvironmentForCompiler(), which checks whether the actual compilers exe-folder is in path and  if it is not already there, it adds it.
Then it rearranges the PATH, so the folder is always the first one.

Does it really make sense to cache the old PATH ?

What can happen as worst case ?
The user uses many different compilers (with different exe-folders) in one C::B session.
Everytime he uses a new one, which is not already in PATH, the path is increased.
But if he uses one, that was already in PATH (either system-path, or by a previous run of SetEnvironmentForCompiler(), the size does not change.

It is of course possible, that the PATH exceeds the maximum size allowed by the system, but this is not very likely I think.

I think it should be save to remove the caching at all, and probably put both functions together to one.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #28 on: February 13, 2012, 10:18:11 am »
I think it should be save to remove the caching at all, and probably put both functions together to one.
Careful: Assume you have a project which uses e.g. GCC3 and GCC4 compiler. In that case having an old PATH in front (GCC3) may result in an error if you just /prepend the new (GCC4) one and probably missed some some additional PATH's. Even worse with VC compilers: They usually need a lot additional PATH's (to SDK tools, for example). So if the compiler you want to use is mis-configured, but a compiler you did use pointed to a path with executables of the same name (but wrong version) you end up screwed. I guess the errors in such a case would be really hard to track.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #29 on: February 13, 2012, 10:26:18 am »
I guess instead off caching, a better solution would be:
- you read what's currently in the PATH
- you check what needs to be prepended (so it is the folder looked into first)
- if it's not already in the PATH (at front) you put it there in front

So, assume you path is as follows:
C:\LALA
Your projects uses MinGW, so you need to prepend C:\MinGW\bin and C:\Tools\Bin, you end up in:
C:\MinGW\bin;C:\Tools\Bin;C:\LALA
Next time, you use MSVC, so you need to prepend C:\MSVC\bin and C:\WinSDK\Bin you end up in:
C:\MSVC\bin;C:\WinSDK\Bin;C:\MinGW\bin;C:\Tools\Bin;C:\LALA
Next time, you use MinGW again, you end up in:
C:\MinGW\bin;C:\Tools\Bin;C:\MSVC\bin;C:\WinSDK\Bin;C:\MinGW\bin;C:\Tools\Bin;C:\LALA

A clean-up step could remove any obsolete / path's appearing twice. I think there is even a nice wxWidgets class for this, namely wxPathList that helps a lot with the dirty work.

EDIT: One thing to consider for us are macros here btw!
« Last Edit: February 13, 2012, 10:28:23 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: EnvVars Plugin and PATH
« Reply #30 on: February 13, 2012, 11:07:38 am »
I guess instead off caching, a better solution would be:
- you read what's currently in the PATH
- you check what needs to be prepended (so it is the folder looked into first)
- if it's not already in the PATH (at front) you put it there in front

So, assume you path is as follows:
C:\LALA
Your projects uses MinGW, so you need to prepend C:\MinGW\bin and C:\Tools\Bin, you end up in:
C:\MinGW\bin;C:\Tools\Bin;C:\LALA
Next time, you use MSVC, so you need to prepend C:\MSVC\bin and C:\WinSDK\Bin you end up in:
C:\MSVC\bin;C:\WinSDK\Bin;C:\MinGW\bin;C:\Tools\Bin;C:\LALA
Next time, you use MinGW again, you end up in:
C:\MinGW\bin;C:\Tools\Bin;C:\MSVC\bin;C:\WinSDK\Bin;C:\MinGW\bin;C:\Tools\Bin;C:\LALA

A clean-up step could remove any obsolete / path's appearing twice. I think there is even a nice wxWidgets class for this, namely wxPathList that helps a lot with the dirty work.

EDIT: One thing to consider for us are macros here btw!

That should be  more or less what is done at the moment, see:
http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=5344&peg=5344

Needed master path and extra path always are prepended, to come first, doubles are removed.
If the toolchain is not setup correctly, there is nothing we can do in any case.

Actually we should get a path that looks like:

masterpath;extrapaths(s);currentpath_without_masterpath_and_extrapath(s)
Or with your example:

  • C:\LALA
  • C:\MinGW\bin;C:\Tools\Bin;C:\LALA
  • C:\MSVC\bin;C:\WinSDK\Bin;C:\MinGW\bin;C:\Tools\Bin;C:\LALA
  • C:\MinGW\bin;C:\Tools\Bin;C:\MSVC\bin;C:\WinSDK\Bin;C:\LALA

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #31 on: February 13, 2012, 11:18:53 am »
That should be  more or less what is done at the moment, see:
http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=5344&peg=5344
Yes, I've seen that already... But the current code is (sorry to say that, but...) a mess. :(

Actually we should get a path that looks like:
masterpath;extrapaths(s);currentpath_without_masterpath_and_extrapath(s)
Working on that... got it soon... will post here... ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: EnvVars Plugin and PATH
« Reply #32 on: February 13, 2012, 11:31:28 am »
That should be  more or less what is done at the moment, see:
http://svn.berlios.de/wsvn/codeblocks/?op=revision&rev=5344&peg=5344
Yes, I've seen that already... But the current code is (sorry to say that, but...) a mess. :(
That's correct, it's grown over some years and was never cleaned up.
So it looks chaotic and has codeparts that are no longer used (like oldpath).

Actually we should get a path that looks like:
masterpath;extrapaths(s);currentpath_without_masterpath_and_extrapath(s)
Working on that... got it soon... will post here... ;-)
It should work exactly like this at the moment, and it should be platform independent due to the use of wxPathList (without the need for us to care about different PATH-specs).

But the main question was/is:
do we really need to cache the systempath.
Can it be harmful not to do it (besides a probably misconfiguration by the user) ?

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #33 on: February 13, 2012, 11:53:18 am »
But the main question was/is:
do we really need to cache the systempath.
Can it be harmful not to do it (besides a probably misconfiguration by the user) ?
No, we don't - that's the root of the original issue.

OK - I did some clean-up, merged the two methods into one as you proposed. Here is the new code, that should be really bullet-proof:
Code
void CompilerGCC::SetupEnvironment()
{
    if (!CompilerFactory::GetCompiler(m_CompilerId))
        return;

    m_EnvironmentMsg.Clear();

    // look for valid compiler in path
    wxString pathDummy;
    if ( !wxGetEnv(_T("PATH"), &pathDummy) )
    {
        m_EnvironmentMsg = _("Could not read the PATH environment variable!\n"
                             "This can't be good. There may be problems running "
                             "system commands and the application might not behave "
                             "the way it was designed to...");
        return;
    }

    Manager::Get()->GetLogManager()->DebugLog(_T("PATH environment:"));
    Manager::Get()->GetLogManager()->DebugLog(pathDummy);

    const wxString pathSep = wxFileName::GetPathSeparator(); // "\\" or "/"

    // Pre-pend the compiler's master path
    Compiler* compiler = CompilerFactory::GetCompiler(m_CompilerId);
    if (!compiler)
        return;

    wxString masterPath = compiler->GetMasterPath();
    Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPath);
    while (masterPath.Last() == '\\' || masterPath.Last() == '/')
        masterPath.RemoveLast();

    wxString      cApp       = compiler->GetPrograms().C;
    wxArrayString extraPaths = compiler->GetExtraPaths();
    wxString      extraPathsBinPath(wxEmptyString);

    // compile new PATH list:
    wxPathList pathList;
    if ( !masterPath.Trim().IsEmpty() ) // would be very bad, if it *is* empty
    {
        // pre-pend "master path", "master path\bin" and "extra path's"
        pathList.Add(masterPath); // in case there is no "bin" sub-folder
        pathList.Add(masterPath + pathSep + _T("bin"));
    }
    for (unsigned int i=0; i<extraPaths.GetCount(); ++i)
    {
        wxString extraPath = extraPaths[i];
        Manager::Get()->GetMacrosManager()->ReplaceMacros(extraPath);
        while (extraPath.Last() == '\\' || extraPath.Last() == '/')
            extraPath.RemoveLast();
        if (!extraPath.Trim().IsEmpty())
        {
            // Remember, if we found the C application in the extra path's:
            if (   extraPathsBinPath.IsEmpty()
                && wxFileExists(extraPath + pathSep + cApp ) )
                extraPathsBinPath = extraPath;
            pathList.Add(extraPath);
        }
    }
    // append what has already been in the PATH envvar
    pathList.AddEnvList(_T("PATH"));

    bool caseSens = !(platform::windows);

    // try to locate the path to the C compiler:
    // it seems, under Win32, the above command doesn't search in paths with spaces...
    // look directly for the file in question in masterPath
    wxString binPath = pathList.FindAbsoluteValidPath(cApp);
    if (    binPath.IsEmpty()
        || (pathList.Index(wxPathOnly(binPath), caseSens) == wxNOT_FOUND) )
    {
        if      (wxFileExists(masterPath + pathSep + _T("bin") + pathSep + cApp))
            binPath = masterPath + pathSep + _T("bin");
        else if (wxFileExists(masterPath + pathSep + cApp))
            binPath = masterPath;
        else if (!extraPathsBinPath.IsEmpty())
            binPath = extraPathsBinPath;
    }
    else
        binPath = wxPathOnly(binPath);

    // Try again...
    if (    binPath.IsEmpty()
        || (pathList.Index(wxPathOnly(binPath), caseSens)==wxNOT_FOUND) )
    {
        m_EnvironmentMsg << _("Can't find compiler executable in your search path's for ") << compiler->GetName() << _T('\n');
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Can't find compiler executable in your search path's (for %s)..."), compiler->GetName().wx_str()));

        return; // failed to locate compiler executable in path's as provided
    }

    // Clean-up step: Locate duplicate entries and remove them
    wxArrayString envPathArr;
    for (size_t i=0; i<pathList.GetCount(); ++i)
    {
        wxString path = pathList[i].Trim();
        while (path.Last() == '\\' || path.Last() == '/')
            path.RemoveLast();
        if ( !path.IsEmpty() )
        {
            path += pathSep;
            if ( envPathArr.Index(path, caseSens)==wxNOT_FOUND )
                envPathArr.Add(path);
        }
    }

    // Compile the separator used to separate path's in envvars:
    wxString path_app; // used in envvar to separate path's
    if (platform::windows) path_app = _T(";"); else path_app = _T(":");

    // Convert the PATH variable array into a string to apply.
    wxString envPath(binPath + pathSep + path_app); // make sure the bin-path we found is in front
    for (size_t i=0; i<envPathArr.GetCount(); ++i)
    {
        // Skip path to binary we added in front already:
        if ( !envPathArr[i].IsSameAs(binPath + pathSep) )
            envPath += (envPathArr[i] + path_app);
    }

    Manager::Get()->GetLogManager()->DebugLog(_T("Updating compiler PATH environment:"));
    Manager::Get()->GetLogManager()->DebugLog(envPath);
    wxSetEnv(_T("PATH"), envPath);
}

EDIT: For syntax highlighting, see here:
http://pastebin.com/AcXYpNr3

I'll try myself, feel free to inspect and try, too...

Comments?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: EnvVars Plugin and PATH
« Reply #34 on: February 13, 2012, 11:57:56 am »
Comments?

// Style zealot hat on
Calling Manager::Get()->GetXXXManager() on multiple lines looks wrong and ugly to me
// Style zealot hat off
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #35 on: February 13, 2012, 12:11:37 pm »
// Style zealot hat on
Calling Manager::Get()->GetXXXManager() on multiple lines looks wrong and ugly to me
// Style zealot hat off
These debug messages will (of-course) be commented later before commit. And then, if you want to see only one of these, you'll need this Manager::Get()->GetXXXManager() stuff... :-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: EnvVars Plugin and PATH
« Reply #36 on: February 13, 2012, 12:18:32 pm »
Leaving commented code is event uglier :)
If you want to do that, why don't you define some marco? :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #37 on: February 13, 2012, 12:21:35 pm »
If you want to do that, why don't you define some marco? :)
I recall you have been the one that said macros are ugly. ;-)

Seriously: A macro doesn't help here. Because these debug messages are there to debug a specific function, so IMHO it's easier to leave it commented and un-comment if needed rather then to have a million macros to enable debug messages for a certain/specific function on demand. Might be just my habit though...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: EnvVars Plugin and PATH
« Reply #38 on: February 13, 2012, 12:39:48 pm »
I recall you have been the one that said macros are ugly. ;-)
In that particular case it was pretty ugly :)

Leaving commented code is pretty ambiguous,
because the reader of the code doesn't know the true intentions of the writer of the code.
Using per file macros is the better way to do it:)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #39 on: February 13, 2012, 12:52:53 pm »
Using per file macros is the better way to do it:)
Again: In this case the compiler has many functions and I usually don't want to debug all of them.

Leaving commented code is pretty ambiguous,
because the reader of the code doesn't know the true intentions of the writer of the code.
I think it should be clear by:
Manager::Get()->GetLogManager()->DebugLog( BLAH );

I think there is no generic "always working - always good" way.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: EnvVars Plugin and PATH
« Reply #40 on: February 14, 2012, 09:10:18 am »
I'll try myself, feel free to inspect and try, too...

Comments?

Another one to test:
Code
void CompilerGCC::SetupEnvironment()
{
    Compiler* compiler = CompilerFactory::GetCompiler(m_CompilerId);

    if (!compiler)
        return;

    wxString currentPath;
    if ( !wxGetEnv(_T("PATH"), &currentPath) )
    {
        InfoWindow::Display(_("Environment error"),
                            _("Could not read the PATH environment variable!\n"
                              "This can't be good. There may be problems running\n"
                              "system commands and the application might not behave\n"
                              "the way it was designed to..."),
                            15000, 3000);
        return;
    }

    Manager::Get()->GetLogManager()->DebugLogError(_T("PATH environment:"));
    Manager::Get()->GetLogManager()->DebugLogError(currentPath);

    const wxString sep=platform::windows?_T(";"):_T(":");
    const wxString pathSep = wxFileName::GetPathSeparator(); // "\\" or "/"

    wxString      cApp       = compiler->GetPrograms().C;
    wxArrayString extraPaths = compiler->GetExtraPaths();
    wxString      extraPathsBinPath(wxEmptyString);

    // Get configured masterpath, expand macros and remove trailing seperators
    wxString masterPath = compiler->GetMasterPath();
    Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPath);
    while (masterPath.Last() == '\\' || masterPath.Last() == '/')
        masterPath.RemoveLast();

    // Prepend "masterpath/bin" and "masterpath"
    wxPathList pathList;
    if ( !masterPath.Trim().IsEmpty() ) // would be very bad, if it *is* empty
    {
        pathList.Add(masterPath + pathSep + _T("bin"));
        pathList.Add(masterPath); // in case there is no "bin" sub-folder
    }

    // Get configured extrapath(s), expand macros and remove trailing seperators
    for (size_t i=0; i<extraPaths.GetCount(); ++i)
    {
        wxString extraPath = extraPaths[i];
        Manager::Get()->GetMacrosManager()->ReplaceMacros(extraPath);
        while (extraPath.Last() == '\\' || extraPath.Last() == '/')
            extraPath.RemoveLast();
        if (!extraPath.Trim().IsEmpty())
        {
            // Remember, if we found the C application in the extra path's:
            if ( extraPathsBinPath.IsEmpty()
                && wxFileExists(extraPath + pathSep + cApp ) )
                    extraPathsBinPath = extraPath;
            pathList.Add(extraPath);
        }
    }


    // append what has already been in the PATH envvar
    // if we do it this way, paths are automatically normalized
    // and doubles are removed
    wxPathList pathArray;
    pathArray.AddEnvList(_T("PATH"));

    pathList.Add(pathArray);

    bool caseSense = !(platform::windows);

    // try to locate the path to the C compiler:
    wxString binPath = pathList.FindAbsoluteValidPath(cApp);

    // it seems, under Win32, the above command doesn't search in paths with spaces...
    // look directly for the file in question in masterPath if it is not already found
    if (binPath.IsEmpty()
        || (pathList.Index(wxPathOnly(binPath), caseSense) == wxNOT_FOUND) )
    {
        if (wxFileExists(masterPath + pathSep + _T("bin") + pathSep + cApp))
            binPath = masterPath + pathSep + _T("bin");
        else if (wxFileExists(masterPath + pathSep + cApp))
            binPath = masterPath;
        else if (!extraPathsBinPath.IsEmpty())
            binPath = extraPathsBinPath;
    }
    else
        binPath = wxPathOnly(binPath);

/* TODO (jens#1#): Is the above correct ?
Or should we search in the whole systempath (pathList in this case) for the executable ?*/
    // Try again...
    if ( binPath.IsEmpty() ||
        (pathList.Index(wxPathOnly(binPath), caseSense) == wxNOT_FOUND) )
    {
        InfoWindow::Display(_("Environment error"),
                            _("Can't find compiler executable in your configured search path's for ") + compiler->GetName() + _T('\n'));
        Manager::Get()->GetLogManager()->DebugLogError(F(_T("Can't find compiler executable in your configured search path's (for %s)..."), compiler->GetName().wx_str()));

        return; // failed to locate compiler executable in path's as provided
    }

    // Convert the pathList into a string to apply.
    wxString envPath(binPath); // make sure the bin-path we found is in front
    // and remove it from pathList
    pathList.Remove(binPath);

    for (size_t i=0; i<pathList.GetCount(); ++i)
    {
            envPath += (sep + pathList[i] );
    }

    Manager::Get()->GetLogManager()->DebugLogError(_T("Updating compiler PATH environment:"));
    Manager::Get()->GetLogManager()->DebugLogError(envPath);
    wxSetEnv(_T("PATH"), envPath);
}

I mades some changes, they are mostly commented in the sources.
It avoids the trailing path-seperators in the path(s)  and the trailing seperator at the end of the system-path value.
I use the ability of wxPathList to avoid doubles and to normalize the paths, to avoid redundance.
I do not use m_EnvironmentMsg, because it isonly used for generated makefiles, which are not supported since ages.

It's tested on linux, but not (yet) on windows, seems to work as expected.

By the way (and off-topic here):
I think we should remove all the makefile generation stuff from our sources, because it is not used anymore.
We have a working (as far as I know) tool from the community to create makefiles from project files, that works (again as far as I know) much better and can surely be wrapped by (or possibly be converted to) a plugin to fully integrate it into C::B.

EDIT:


I think it's safer to use:
Code
    wxPathList pathArray;
    pathArray.AddEnvList(_T("PATH"));

instead of

Code
    wxArrayString pathArray = GetArrayFromString(currentPath, sep);

I changed it in the codesnippet above.
« Last Edit: February 14, 2012, 10:18:25 am by jens »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #41 on: February 14, 2012, 10:46:10 am »
Another one to test:
Looks fine to me, too.

By the way (and off-topic here):
I think we should remove all the makefile generation stuff from our sources, because it is not used anymore.
Certainly tru. And (in fact) I did this already in my local copy literally since ages. I have a rather cleaned-up compiler plugin basically ready to commit for that purpose (that's also, why I can hardly provide true patches). So if there are no objections, I could step-by-step commit the changes.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: EnvVars Plugin and PATH
« Reply #42 on: February 14, 2012, 11:13:04 am »
Concerning this:
Code
    /* TODO (jens#1#): Is the above correct ?
       Or should we search in the whole systempath (pathList in this case) for the executable? */
Yes, I think its correct. We should enforce that the user does a correct setup of the compiler. Otherwise we don't know, if we picked the right compiler if we search the whole system path. We may even find a wrong one, probably for another platform (avr) which we pick then as "correct". This can only go wrong and we will have a lot of trouble question in the forums hard to track.

But what might be wrong is the fact, tat we only check for the C compiler. For a C++ project this might not be needed. And for a Makefile project not, too.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: EnvVars Plugin and PATH
« Reply #43 on: April 07, 2013, 06:50:51 am »
Is this issue fixed in the trunk?

To solve the problem I describe here: Does Compiler plugin automatically add lib search path to PATH environment, I need to modify PATH variable in the EnvVars plugin by setting the PATH variable to "%PATH%;E:\code\opencv\OpenCV-2.4.4\opencv\build\x86\mingw\bin;E:\code\gcc\nixman463dw2\bin", just the steps described in pkrcel's original post EnvVars Plugin and PATH, it works OK (C::B rev 8896)

I'm not clear how compiler plugin modify PATH, in my case, my compiler Tool Chain executable path is: E:\code\gcc\PCXMinGW463, but as the opencv library is prebuild, it need a libstdc++-6.dll, so I add the E:\code\gcc\nixman463dw2\bin to the PATH. So, I can guess that when compiling, I have two gcc paths. Does the compiler plugin always put the "Tool Chain executable path" path in the front of the PATH? I mean, the executables under "E:\code\gcc\PCXMinGW463" will be chosen to build my app?

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.