a Qt plugin : QtPregenForCB => AddOnForQt

[LETARTARE]

From January 01, 2020, 'Qtpregen' will be replaced by 'Addonforqt'
http://forums.codeblocks.org/index.php/topic,20000.msg165730.html#msg165730

Hello everyone,
I suggest a plugin for compiling Qt project using Code::Blocks .
This extension of  Code::Blocks will be offered on:
https://github.com/LETARTARE/QtPregenForCB
and is called :

QtPregenForCB-0.2.2

If this plugin interested persons, I would do an article in the Wiki.

See the discussion: http://forums.codeblocks.org/index.php/topic,19931.0.html
Sincerely

[LETARTARE]

Hello,
I forgot to provide patches for 'Code::Blocks'  (svn 9501, 10035, 10091)  !!
It is repaired.
https://github.com/LETARTARE/QtPregenForCB
Sincerely

[MortenMacFly]

I forgot to provide patches for 'Code::Blocks'  (svn 9501, 10035, 10091)  !!

...in SVN. I see no reason why we should not do this. However, keep the comments of obfuscated in mind... To be bullet-proof the event ID's should be standardised and exposed through the SDK. So this actually is only half of the way...

[oBFusCATed]

I still don't think this is a good solution, in fact I think this is terrible solution and if it was up to me I'd revert it.

For example the current version of the plugin will break if the user uses the context menu in the project manager.
It will break, if the compilation is started by a script. Or even from the debugger.

If you need to know something like a reason why the event has been fired then we should use some kind enum for the task.

[MortenMacFly]

If you need to know something like a reason why the event has been fired then we should use some kind enum for the task.

Thats what I meant with:

To be bullet-proof the event ID's should be standardised and exposed through the SDK.

However, in the compiler you'd then only replace the int ID with an enum ID. Therefore the code is "kind of" valid. I didn't state that its correct to use the ID's as done in the plugin.

[oBFusCATed]

But still how do you know that the value of the m_EventId is set correctly before we the event is fired?
There is no code to reset it. So if the event is fired from a different code-path than the one expected it will be fired with invalid information.

Shouldn't we add more fine grained events that make the implementation of this plugin possible?

From the code of the plugin I can see that it is interested to know if a project is cleaned, built or if a single file is compiled (but does nothing in this case).

Should I revert this commit or you'll do it? 

[LETARTARE]

Hello,
thank you very much to both of you for your advice.
@MortenMacFly
Thanks for the commit to svn 10115 

@oBFusCATed
I'm not sure I understood ?

For example the current version of the plugin will break if the user uses the context menu in the project manager.

because actually I can use the context menu 'Build, Rebuild, Clean' with no break.

From the code of the plugin I can see that it is interested to know if a project is cleaned, built or if a single file is compiled (but does nothing in this case).

Yes, it is exactly that. For a single file I still wonder about the work to be done?

Anyway, if you have a different solution, with the current svn, I take.

Another question:
Is it possible to use the 'Build log' to display messages generated by the pre-generate ?
This would be more consistent than display them in 'Code::Blocks log'.

Sincerely.

[oBFusCATed]

because actually I can use the context menu 'Build, Rebuild, Clean' with no break.

I doubt, because they have different ids, as far as I can see.
Have you tried to use them just after you've started a fresh instance of C::B?

[LETARTARE]

I'll try because I am trying to compile svn 10116...

[LETARTARE]

I confim...
I use svn 10116, rebuilt the plugin and context menus work correctly.
I'll check id's for safety ...
'QtPregenForCB' must be loaded after 'CompilerGcc',  but that's always the case !
I did a test by changing the name of the plugin 'CbqtPregen', and there the id's become -1!

[oBFusCATed]

I can believe you. There is no chance for this to work.
This is the code that registers the context menu items. Obviously the items don't reuse the ids from the main menu.
And I couldn't see any code that takes these ids.

Code

        menu->Append(idMenuCompileFromProjectManager, _("Build"));
        menu->Append(idMenuRebuildFromProjectManager, _("Rebuild"));
        menu->Append(idMenuCleanFromProjectManager,   _("Clean"));

The dependence on the plugin load order is another nail in the coffin of this change! 

[oBFusCATed]

If you need to make a robust solution.
Take a look at the CompilerGCC::BuildStateManagement function. There is a switch for every build action.
You can invent an event that fires in this specific moment so it will always be correct.
You can add events that fire at the end of the action. So you will know when clean has started and also you'll know when it has finished. Also you'll know the same things about the other phases of the build.

Also there are the cbEVT_CLEAN_PROJECT_STARTED and cbEVT_CLEAN_WORKSPACE_STARTED events.

[LETARTARE]

I ask that you check, you'll see!

For

Code

 menu->Append(idMenuCompileFromProjectManager, _("Build"));
menu->Append(idMenuRebuildFromProjectManager, _("Rebuild"));
menu->Append(idMenuCleanFromProjectManager,   _("Clean"));

A little higher in the Dispatcher:

Code

void CompilerGCC::Dispatcher(wxCommandEvent& event)
{
    m_EventId = event.GetId();
//    Manager::Get()->GetMessageManager()->Log(wxT("Dispatcher")));
    if (m_EventId == idMenuRun)
        OnRun(event);
    else if (m_EventId == idMenuCompileAndRun)
        OnCompileAndRun(event);
    else if (m_EventId == idMenuCompile)
        OnCompile(event);
    else if (m_EventId == idMenuCompileFromProjectManager)
        OnCompile(event);
    else if (m_EventId == idMenuCompileFile)
        OnCompileFile(event);
    else if (m_EventId == idMenuCompileFileFromProjectManager)
        OnCompileFile(event);
    else if (m_EventId == idMenuCleanFileFromProjectManager)
        OnCleanFile(event);
    else if (m_EventId == idMenuRebuild)
        OnRebuild(event);
    else if (m_EventId == idMenuRebuildFromProjectManager)
        OnRebuild(event);
....

we recover the same id's

idMenuCompileFromProjectManager
idMenuCleanFileFromProjectManager
idMenuRebuildFromProjectManager

triggers

OnCompile(event);
OnRebuild(event);

Take a look at the CompilerGCC::BuildStateManagement function.

I will try to understand how it works to use.

[oBFusCATed]

I don't understand what you mean with the last post.
Do you agree that there is no chance for your plugin to work correctly when someone is using the context menu or are you seeing something in the code that I'm missing?

I ask that you check, you'll see!

I don't understand the meaning of this sentence.

[LETARTARE]

I ask you to try the plugin 'QtPregenForCB' to verify that the context menu works correctly.