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

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: 9594
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: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://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: 9594
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: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://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: 6896
    • 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 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
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: 9594
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: [Select]
   if (!m_OriginalPath.IsEmpty())
        wxSetEnv(_T("PATH"), m_OriginalPath);
...and replace it with:
Code: [Select]
   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: [Select]
       envPath = envPath + GetStringFromArray(envPathArr, path_sep, false);
        wxSetEnv(_T("PATH"), envPath);
...and replace it with:
Code: [Select]
       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: [Select]
<?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: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://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: 9594
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: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7253
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
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: 12597
    • 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 jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7253
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
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: 9594
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: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9594
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: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ