Adding 12 cached gcc dirs to parser...

[rickg22]

Adding 12 cached gcc dirs to parser...
Adding 12 cached gcc dirs to parser...
Adding 12 cached gcc dirs to parser...

Can someone explain to me why this is called around a million times in the Code completion plugin?

[MortenMacFly]

Can someone explain to me why this is called around a million times in the Code completion plugin?

I can (in the end I'm afraid it's my code... ;-):
In early times C::B called the GCC compiler on every (!) project/target it opened to gather the MinGW internal include directories required for the parser. This was very expensive and time consuming. I changed that so that the GCC is called once per C::B session (how likely is it you change the compiler while working with C::B?!). Hence these directories are cached and provided by request (still the parser needs them for every project you open). You can disable the debug message if you like... it's obviously confusing (nativeparser.cpp, line 409). But I'd rather leave the functionality as it is - it works and is fast. ;-)
With regards, Morten.

[David Perfors]

But I'd rather leave the functionality as it is - it works and is fast. ;-)

Wouldn't it be better (faster, easier) to save the cache to disk...

[MortenMacFly]

Wouldn't it be better (faster, easier) to save the cache to disk...

Depends on what do you mean by "cache". These GCC dirs are only 12 (in my case even only 4) directory strings in a wxArrayString. For this I wouldn't do a HDD cache...?!
With regards, Morten.

[David Perfors]

Well, I thought that the content of those directories where parsed at that stage by the CC plugin. Obviously I was thinking wrong (I must admit, I didn't look into the source code )

[Ceniza]

Now that we're talking about that, would it be possible to delay that call? So far it seems to be the reason why starting Code::Blocks on Linux with a project or workspace as parameter (in other words: launching Code::Blocks by clicking on one of those files) freezes it. If the project or workspace is small enough nothing happens, but if it's a bit bigger then Code::Blocks won't be able to open it and will just hang in there forever, or at least that happens here.

I do really think it would be wise to do all that kind of things (like executing processes to retrieve information from them) only after the App and MainFrame have been fully created. It would make, basically, some plugins to be created in two stages: the first one OnLoad which should be a very basic initialization, and the second one when the application has been fully created and it's ready to start doing extra work. I haven't checked if there's an event for that already, but it could be created if it is not.

Ideas, opinions, complaints?

[rickg22]

Yesterday i finished implementing an event JUST for that.

It's called EVT_WORKSPACE_LOADED, and it's triggered when C::B has finished loading/closing a project/workspace.