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

Expand Envvars Plugin to Compiler Executables Path

<< < (2/3) > >>

scarphin:

--- Quote from: MortenMacFly on January 28, 2015, 07:51:43 pm ---
--- 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".

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

--- Quote from: MortenMacFly on January 28, 2015, 07:51:43 pm ---
--- 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...

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

--- Quote from: MortenMacFly on January 28, 2015, 10:19:05 pm ---Are you aware that you can define envvar sets per project in the project settings?

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

--- Quote from: scarphin on January 28, 2015, 02:37:21 am ---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.

--- End quote ---


--- Quote from: MortenMacFly on January 28, 2015, 10:19:05 pm ---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?

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page