Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Expand Envvars Plugin to Compiler Executables Path

(1/3) > >>

scarphin:
I'm trying to configure different versions of a single compiler entry on a per project basis. I tried setting a 'CVER' environmental variable in 'setting -> environment -> environmental variables -> default set' and inserted it in the toolchain executables path for the compiler entry. Changing the 'CVER' value to something else or creating a new envvar set with a different 'CVER' variable and setting it doesn't change the compiler executable path. Path gets updated only if compiler settings are modified. Is there a way I can achieve this other than creating multiple copies of same compiler for different versions?

Also how does cb handle compiler paths as cb only includes the compiler executable in the command line like 'g++.exe -Wall ...'? How does 'g++.exe' doesn't mix with another 'g++.exe' which comes before in the system path? I guess cb configures the path with the target compiler folder before launching build steps, is that it?

MortenMacFly:

--- Quote from: scarphin on January 27, 2015, 03:40:15 am ---Also how does cb handle compiler paths as cb only includes the compiler executable in the command line like 'g++.exe -Wall ...'?

--- End quote ---
C::B prepends the actual compiler's PATH on front of the environment variable before calling the compiler. So instead of:
PATH=C:\Program files\FooCompiler\bin
...it gets:
PATH=D:\Codeblocks\MinGW\bin;C:\Program files\FooCompiler\bin
...thus definitely calling the right executables.

MortenMacFly:

--- Quote from: scarphin on January 27, 2015, 03:40:15 am ---I'm trying to configure different versions of a single compiler entry on a per project basis.

--- End quote ---
Either make copies of the compiler as needed and adjust the path OR you could play with GCV's, these should be evaluated at runtime.

So set the compiler path to: $(#COMPILER.bin)

...and (re-)defining the GCV as needed. Could even work with the project environment variables, but I am not sure.

scarphin:
Thanks for the info. Fortunately I was mistaken and my approach actually works but with a single problem. When the project is set the load an envvars set, it is loaded after code-completion plugin starts parsing and although the compiler executables are set correctly, cc parses the wrong directory. If the corresponding envvars are set before the project is loaded everything works fine. I have no idea if the invoke order of the 'OnProjectActivated' of plugins can be changed when an event is fired so I tested by registering the envvar plugin to 'cbEVT_PROJECT_OPEN' instead of 'cbEVT_PROJECT_ACTIVATED' (therefore giving higher priority to envvars plugin) and everything worked without manual interruption. How can this situation be dealt with?

I also spotted a weird behavior which I believe is a bug. When 'Setting -> Environment' is launched, envvars plugin sets the default set no matter what because of the 'LoadSettings()' call in 'EnvVarsConfigDlg::EnvVarsConfigDlg'. I think settings should be loaded at some place where they are only initialized once.

MortenMacFly:

--- Quote from: scarphin on January 28, 2015, 02:37:21 am ---How can this situation be dealt with?

--- End quote ---
Well good question. I implemented setting the envvars on purpose into "activated", because otherwise if you have a large workspace with many projects you set envars over and over again for no specific reason. However, if you activate a project you want to work with it, so this makes sense. Also, if you put it into "open" I wonder what happens if you open another project within a WS and then activate another project already existing. This should screw your envvars unless you set them in both: "activated" and "open".


--- Quote from: scarphin on January 28, 2015, 02:37:21 am ---I also spotted a weird behavior which I believe is a bug. When 'Setting -> Environment' is launched, envvars plugin sets the default set no matter what because of the 'LoadSettings()' call in 'EnvVarsConfigDlg::EnvVarsConfigDlg'. I think settings should be loaded at some place where they are only initialized once.

--- End quote ---
Good spot... Well I want to read the settings here becasue they might have changed... Maybe LoadSettings() should have a flag not to apply them in this case... I don't recall if thats meaningful, I'll have to have a look...

Navigation

[0] Message Index

[#] Next page