Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

EnvVars Plugin and PATH

<< < (6/9) > >>

Jenna:
I tend to 2., but have to look into it.

oBFusCATed:
+1 for 2

Jenna:
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.

MortenMacFly:

--- Quote from: jens on February 13, 2012, 09:54:18 am ---I think it should be save to remove the caching at all, and probably put both functions together to one.

--- End quote ---
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.

MortenMacFly:
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!

Navigation

[0] Message Index

[#] Next page

[*] Previous page