QtWorkbench plugin

[yop]

What is it?
A plugin that adds support for Qt to the Code::Blocks IDE
How?
Using qmake, Trolltech's makefile generator, included in every Qt installation. The plugin generates input files (.pro files) for qmake and then runs it to generate a makefile. Using the internal Code::Blocks support for Makefiles you can build your project and have all the features that C::B provides available.

More information in: http://code.google.com/p/qtworkbench/
Get the sources using svn (be carefull of wrapping):
svn checkout http://qtworkbench.googlecode.com/svn/trunk/ [C::B sources dir]/src/plugins/contrib/qtworkbench
Binaries: http://code.google.com/p/qtworkbench/downloads/list

[mandrav]

Nice job

And the best way would be to trigger somehow a makefile build. The only way I can see that being possible is to get the makefile build process out of the compiler plugin and into the core.

If you automatically set the project to use a custom makefile, then the following is sufficient:

Code: cpp

// find compiler plugin
PluginsArray arr = Manager::Get()->GetPluginManager()->GetCompilerOffers();
if (arr.GetCount() == 0)
    return;

cbCompilerPlugin* compiler = static_cast<cbCompilerPlugin*>(arr[0]);
if (compiler)
{
    // we have our compiler!
    // start building
    compiler->Build(targetName); // use <target_name> or leave <empty> for project build

    // wait for compiler to finish
    while (compiler->IsRunning())
    {
        // if you want to abort the build, ucomment the following:
        //compiler->KillProcess();

        wxMilliSleep(10);
        Manager::Yield();
    }
    int exitCode = compiler->GetExitCode();

    // ta-da!
}

HTH.

[yop]

Well I've also created my plugin as a compiler plugin, are we sure that the compilergcc plugin will be in arr[0]? Now that I think about it my plugin doesn't have to be a compiler plugin at all... Let me see what I can figure out. And yes you 've helped a lot

[mandrav]

Well I've also created my plugin as a compiler plugin, are we sure that the compilergcc plugin will be in arr[0]? Now that I think about it my plugin doesn't have to be a compiler plugin at all... Let me see what I can figure out. And yes you 've helped a lot

I see you get the point
Really, there is no reason for more than one compiler plugin loaded at the same time.

[yop]

And ta da it is 
Those 10 something lines of code made all the difference. I'll strip my code from all these obsolete stuff now (message log, calls to make, ...), that is a relief...

[yop]

Houston, We Have a Problem...
Ok before I get the compiler to build I set it to using makefiles and when it finishes I return it to the previous state whatever that was. But this change to the build method produces the dialog "Project modified blah blah" which I would like to avoid.
Secondly I removed my log as it wasn't needed anymore, but I get the messages in the build log flushed when the build process finishes. I had the same behaviour with my log and I had to add the idle wake up timer. Do I also have to implement one although I don't have a log anymore? Doesn't this Yield thing "force" the pending events to be processed (so the buffered build log output should be flushed to the log by the compiler plugin)?

[mandrav]

Ok before I get the compiler to build I set it to using makefiles and when it finishes I return it to the previous state whatever that was. But this change to the build method produces the dialog "Project modified blah blah" which I would like to avoid.

Code: cpp

// keep the old state
bool wasModified = project->GetModified();

// change settings and build...

// revert to old state
// ...
project->SetModified(wasModified);

Secondly I removed my log as it wasn't needed anymore, but I get the messages in the build log flushed when the build process finishes. I had the same behaviour with my log and I had to add the idle wake up timer. Do I also have to implement one although I don't have a log anymore? Doesn't this Yield thing "force" the pending events to be processed (so the buffered build log output should be flushed to the log by the compiler plugin)?

I haven't seen this, but try adding Manager::ProcessPendingEvents() after Manager::Yield() (or replace it).

[yop]

I haven't seen this, but try adding Manager::ProcessPendingEvents() after Manager::Yield() (or replace it).

Replacing it made the whole app non responsive. If I totally comment out the folowing it works like a charm.

Code: cpp

        while (compiler->IsRunning())
        {
            // if you want to abort the build, ucomment the following:
            //compiler->KillProcess();
            wxMilliSleep(10);
            //Manager::Yield();
            Manager::ProcessPendingEvents();
        }

Maybe I should leave it like that (without the while loop) and check compiler->IsRunning(); when the user requests another build, or call compiler->KillProcess(); to stop it and start over.

[yop]

I've updated quite a few things, with the most important ones being linux support, Qt 3 support and multiple compilers support (at least gcc and icc were recognized beautifully) though you will have to delete any old Makefiles created for another compiler. I wasn't really planning on giving an update this early but that compiler ID instead of index change rushed things a bit so here you are (I didn't want any "I can't compile" remarks ). To build this one (namely 0.3) you 'll need at least revision 1967 of codeblocks. You'll also find a project file for linux, I had some problems with backticking wx-config --cflags. If anyone experiences this just give wx-config --cflags to a console and add anything that it outputs to the compiler options and it will build.
I 'll focus on workspace compilation and per target compilation to see what can be done there (it sohuld be easy as I've seen) and continue with the rest of the gui stuff, so it should be a while before I update again. You can get this latest release from the attachment in the first post. Any kind of feedback is welcome,
Yorgos

[yop]

I 've updated to build under the current plugins framework (registering the plugin name). So you 'll need revision 1995 and up to build this one

[krisha]

the first positive about it: i had to download a rev > 1995 (2061) and throw away the rc2 :-)

but now i encounter a problem. I loaded the Win QTWorkbench and it asks me for a global variable wx and cb. What directories to put there ? For cb imho Code::Blocks main directory, but has that QT build process anything todo with wx ( i assume it stands for wxWidgets) ?

edit:

solved some parts:
- cb is the source of codeblocks
- wx is is simply the wxWidgets (for win we have to rename the setup_redirect.h to setup.h)

but now:
ld.exe: cannot find -lcodeblocks
same for wxmsw26u

i thought i use the dll's of that both, but that didn't work. How to get the right lib and where to put it ? Do I have to compile full codeblocks and wxWidgets again ?

if it's not so time consuming, maybe you can put a ready-for-use compiled Qt-Plugin DLL for download here ? I think you have all needed tools/libs to compile by just one click :-) thx.

[yop]

i thought i use the dll's of that both, but that didn't work. How to get the right lib and where to put it ? Do I have to compile full codeblocks and wxWidgets again ?

You need codeblocks lib, so yes you'll have to build codeblocks (I don't know what is in the night builds). For the wxWidgets lib you just have to point to where the specific lib is using the global variables (the "lib" path under the "wx" global variable should point to the folder where the wxWidgets lib is). If you find the correct setup it'll be easy to build it don't worry. As for the precompiled dll I don't find it such a good idea as it might become obsolete very quickly. When a new release of Code::Blocks is out I will provide something like that. Another issue is that for now I don't have any repository to put the dll so it would "waste" forum space.

[iw2nhl]

Hi, I'm here because I'm looking for an IDE for Qt/C++ development.
Using qmake I noticed that you can use it to generate the project file.
If there are troubles generating .pro files, while not use qmake to generate the project?
Here are the simple steps:
1) You have .cpp, .h and .ui files
2) You call "qmake -project [options] <files>" (<files> are your .cpp, .h and .ui files)
3) You call "qmake -makefile [options] project.pro" (or even only "qmake")
4) You can compile with "make" (or "mingw32-make")

Please, tell me if you need help for coding the plugin.
Alessandro

[yop]

Thanks Alessandro for your suggestions. Invoking qmake in the way you propose has limited control on your project options. In general letting qmake generate a .pro file is usefull only for small, single target projects. Sorry for my short and delayed answer but I'm away on a bussiness trip.
Yorgos

[MortenMacFly]

Requested in another thread (http://forums.codeblocks.org/index.php?topic=2761.new) yop asked me to publish the changes I've done (well, project file changes only) here due to some compiling problems others might have.
...so I'm doing this hereby.
With regards, Morten.

Edit: The sources have been removed - meanwhile yop has released a most-up-to-date version that should be used in the first place.