Expand Envvars Plugin to Compiler Executables Path

[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]

Also how does cb handle compiler paths as cb only includes the compiler executable in the command line like 'g++.exe -Wall ...'?

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]

I'm trying to configure different versions of a single compiler entry on a per project basis.

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]

How can this situation be dealt with?

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".

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.

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

[scarphin]

How can this situation be dealt with?

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".

Well, I'm not advocating that they should be set in 'open'. I just tested setting envvars in 'open' to prove they work if set before any other plugin comes into play. 'open' is obviously a bad choice to set them. Maybe changing the plugin loading sequence might work to set the envvars before any other plugin. In what order the plugins are loaded, by name? If yes, what about renaming the plugin to 'aaenvvars' or something (not everywhere, just wherever necessary) to get it to register before any other plugin? I'll try that if I can.

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.

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

If I'm not mistaken, the only place to change the envvar sets is 'settings -> environment -> environment variables'. If so, where would they have been changed requiring them to be read again? Also apart from loading, they are actually set when 'setting -> environment' is launched. After launching, the user doesn't even need to change anything nor even scroll to the 'environment variables' dialogue for envvars to be set to 'default'. That doesn't seem to the correct behavior. Maybe settings should be loaded and set once in 'OnAttach' or the like and let the plugin change them whenever needed. Just guessing.

[MortenMacFly]

Are you aware that you can define envvar sets per project in the project settings? Also, the plugin exposes it's functions to the scripting engine... Maybe you can use the pre-build steps to make sure it's der correctly...as a work around?

[scarphin]

Are you aware that you can define envvar sets per project in the project settings?

I'm already using that setting. I've mentioned it before but maybe that wasn't clear, sorry.

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.

Also, the plugin exposes it's functions to the scripting engine... Maybe you can use the pre-build steps to make sure it's der correctly...as a work around?

As I've also mentioned before that with the current implementation, correct executables for compiler, linker etc... are used for building the project and it builds fine. The problem is the cc plugin parses the wrong folders as it's fed the paths before envvars plugin switches to the correct ones. I don't see a way to correct this with any kind of scripting (maybe I'm wrong) and would it be a reasonable workaround? Btw compiler plugin uses the correct paths because it updates the macros, variables etc... before launching anything.

Currently the only workaround for me is to register the plugin to 'cbEVT_PROJECT_OPEN' with a self build as I only use a single project in the workspace more than most of the time. Somehow giving the plugin higher priority in 'cbEVT_PROJECT_ACTIVATED' seems to be a reasonable general solution but through my extensive google search I have yet to find an answer other than changing the plugin loading order somehow.

[scarphin]

Registering to the 'cbEVT_PROJECT_ACTIVATE' and 'cbEVT_PROJECT_CLOSE' in the 'EnvVars' constructor makes the plugin work correctly. I have no idea what side effects this approach might cause though. I attached a patch demonstrating the changes I've made.

[MortenMacFly]

Ok, I will have a look. For cc, maybe specifying per project files/folders to scan would be another option... These should be scanned first.

[scarphin]

Ok, thanks. I didn't get your point on 'per project files/folders to scan' though. Also can you please enlighten me about the constructor trick, what problems may arise if events are registered inside the constructor?

Btw any confirmation on the 'settings -> environment' bug?

[MortenMacFly]

what problems may arise if events are registered inside the constructor?

Ok - I've seen your patch. The bad thing is, that if you connect in the destructor the plugin will always receive notifications no matter if its enabled or not. So you would have to put a check whether or not the plugin is actually enabled nearly everywhere. So that probably not a good solution.

I think its really a design flag in the plugin system of C::B - we should have something like a weight for plugin to make sure you enabled them in the right order. So sorry, I don't see a better solution for you other than the one you have.

Btw any confirmation on the 'settings -> environment' bug?

No I didn't try so far.

I didn't get your point on 'per project files/folders to scan' though

if you have a project open, goto:
Project settings -> Tab "C/C++Parser" -> Add additional search paths here.