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.
// 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!
}
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
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.
// 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).Replacing it made the whole app non responsive. If I totally comment out the folowing it works like a charm.
while (compiler->IsRunning())
{
// if you want to abort the build, ucomment the following:
//compiler->KillProcess();
wxMilliSleep(10);
//Manager::Yield();
Manager::ProcessPendingEvents();
}
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.
[...] and do I need to install wx to get this to work?You'll need the wxWidgets SDK and the CodeBlocks SDK. So basically you'll need to compile the wxWidgets library and the Code::Blocks SDK before you can compile a(ny) Code::Blocks PlugIn. With RC2 there was also a C::B SDK provided, but this is outdated and will not work.
Morten, did you manage to build it [...]Yes, I build it constantly with every new C::B revision. I use exactly the files as provided in the archive from my other post and it works (integrates into C::B and other things).
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lwxmsw26uA quick search through the forum for "cannot find -lwxmsw26u" would have revealed the reason multiple times: You either have not the wxWidgets SDK installed or the directories for the linker are not setup correctly.
cp -r devel/testCodeBlocks/QtWorkbench/out/share /usr/This is where the rest of the codeblocks plugins' shared files are installed?
Turns out that the file qtworkbench_menu.xrc distributed contains a NUL (0x00) character near the end [...]Now that you say this: Yes! That character I had to remove, too. Anyway: Within the archive I've uploaded in this forum thread this character was already removed. Which version did you use for compiling? The same question I'd like to ask to yop...?!
Which version did you use for compiling?
if(!wxGetEnv(_T("QTDIR"),&cmd))
{
// Not a good Qt installation ;)
wxMessageBox(_T("Error: environment variable QTDIR not found !"));
return 0;
}
Now that you say this: Yes! That character I had to remove, too. Anyway: Within the archive I've uploaded in this forum thread this character was already removed. Which version did you use for compiling? The same question I'd like to ask to yop...?!Version of what?
With regards, Morten.
I took it from the first posting of this thread.The plugin includes (or at least is supposed to) the settings from your C::B project, just add your custom settings to the Project->Build Options dialog and the plugin will generate a .pro file with your settings. I don't just fire and forget qmake, I provide a .pro file instead that "describes" the build process. I 've tested it with projects without Qt and it works just fine (though it adds -lqt in your link options but that's just something you have to live with if you use a trolltech product ;))
Hmm, how do I add non-Qt libraries? Out of CB I include them in the .pro file, adding lines like
...
As I see in your sources, you just fire up the qmake project generator, which is ok for pure Qt but doesn't cut it for more complex projects. You could take information like this from the CB project and add it to the qmake command line so it will include it in the project file like this:
* Run Menu QtWorkbench->Qmake-Clean, same as above, also the qt1.pro file does still exist, which i would expect to be deleted.No it shouldn't be deleted (it would be like deleting foo.cbp from codeblocks project foo when cleaning)
from what i've read in the first posting of this thread from yop , i would expect, that when running QtWorkbench->Qmake-BuildYeap that's it, qmake is just a makefile generator that takes a configuration file as input (the .pro file). QTDIR I 'm afraid is getting outdated, I should change that (it is still there in Qt 4.x but it's not needed for the actual build process).
after building the *.pro file qmake would be invoked to build the makefile and afterwards running make ?? am i wrong ?
As a sidenote, do not use wxMessageBox inside C::B and plugins. Use cbMessageBox instead which places the dialog on the correct screen for multi-head systems.I won't don't worry :)
Version of what?Version of the QTWorkspace plugin. Basically if it's the one of the first post to the thread or the one I posted. It was to see whether the XRC error is still raised allthough I've removed this NUL character. If you were able to compile and had no troubles you can safely ignore this question... which was actually intended as a hint... ;-)
Hmm, no I haven't tried to build the one you uploaded. When i was asked some questions about the plugin I remember downloading the exact same zip file from the first post and built it without any problems.Version of what?Version of the QTWorkspace plugin. Basically if it's the one of the first post to the thread or the one I posted. It was to see whether the XRC error is still raised allthough I've removed this NUL character. If you were able to compile and had no troubles you can safely ignore this question... which was actually intended as a hint... ;-)
With regards, Morten.
The plugin includes (or at least is supposed to) the settings from your C::B project, just add your custom settings to the Project->Build Options dialog and the plugin will generate a .pro file with your settings.
Then it's a bug, I 'll take a look at it thanks. As a temporary solution you can open up the .pro file and add the missing library *outside* the identifiers that say "Code::Blocks identifier" like this: LIBS+=lrdf. Let me know if it works as I want the .pro file I create to let the user edit it by hand (that's why I used identifiers in the first place).QuoteThe plugin includes (or at least is supposed to) the settings from your C::B project, just add your custom settings to the Project->Build Options dialog and the plugin will generate a .pro file with your settings.
That would be great! Then I must be missing something. My project depends on /usr/lib/liblrdf.so. I added "lrdf" to "Build Options | Linker | Link libraries" but this has no influence on the .pro file and the build thus fails. The "include" dirs and the "defines" do appear, though.
Luis
I just want to say that this plugin is awesome. As I said in a previous post, I built it, but hadn't tested it yet. I tested it, and it works flawlessly. I built it on Windows, CB (4/9).:D
like this: LIBS+=lrdf.
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:57: warning: inline function `int qGray(QRgb)' declared as dllimport: attribute ignored
is any way known to suppress these nasty warnings about inlined functions declared as dllimport ?Never got them :? Which compiler are you using?
like this one:QuoteD:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:57: warning: inline function `int qGray(QRgb)' declared as dllimport: attribute ignored
is any way known to suppress these nasty warnings about inlined functions declared as dllimport ?Never got them :? Which compiler are you using?
like this one:QuoteD:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:57: warning: inline function `int qGray(QRgb)' declared as dllimport: attribute ignored
is any way known to suppress these nasty warnings about inlined functions declared as dllimport ?
like this one:QuoteD:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:57: warning: inline function `int qGray(QRgb)' declared as dllimport: attribute ignored
By strange coincidence, I stumbled upon this just today. Here's the strange thing:I thought the same, but it seems it's not the case.
If I compile with -Wall (all warnings, as usual), I don't get these warnings.
If I compile with -W (standard warnings), I get this :?
It's strange because "all warnings" should be a superset of "standard warnings only" ?!?
what gcc version are you using ?is any way known to suppress these nasty warnings about inlined functions declared as dllimport ?
like this one:QuoteD:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:57: warning: inline function `int qGray(QRgb)' declared as dllimport: attribute ignored
By strange coincidence, I stumbled upon this just today. Here's the strange thing:
If I compile with -Wall (all warnings, as usual), I don't get these warnings.
If I compile with -W (standard warnings), I get this :?
It's strange because "all warnings" should be a superset of "standard warnings only" ?!?
what gcc version are you using ?
do you get these warnings from Qt or also from wxWidgets headers ?
-Wextra
(This option used to be called -W. The older name is still supported, but the newer name is more descriptive.)
#include <qstring.h>
#include <qapplication.h>
#include <qpushbutton.h>
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QPushButton quit("Hello World!");
quit.resize(300, 40);
quit.setFont(QFont("Arial", 18, QFont::Bold));
QObject::connect(&quit, SIGNAL(clicked()), &app, SLOT(quit()));
quit.show();
return app.exec();
}
mingw32-make.exe -f Makefile.Release
mingw32-make.exe[1]: Entering directory `D:/Devel/_projects/Qt/qt2'
g++ -c -Wall -O2 -O2 -frtti -fexceptions -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NEEDS_QMAIN -DQT_DLL -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"D:/qt412/include/QtCore" -I"D:/qt412/include/QtGui" -I"D:/qt412/include" -I"D:/MinGW/include" -I"D:/Qt412/include" -I"D:/Qt412/include/ActiveQt" -I"D:/Qt412/include/Qt" -I"D:/Qt412/include/Qt3Support" -I"D:/Qt412/include/QtAssistant" -I"D:/Qt412/include/QtCore" -I"D:/Qt412/include/QtDesigner" -I"D:/Qt412/include/QtGui" -I"D:/Qt412/include/QtNetwork" -I"D:/Qt412/include/QtOpenGL" -I"D:/Qt412/include/QtSql" -I"D:/Qt412/include/QtSvg" -I"D:/Qt412/include/QtTest" -I"D:/Qt412/include/QtUiTools" -I"D:/Qt412/include/QtXml" -I"D:/qt412/include/ActiveQt" -I"release" -I"." -I"D:/qt412/mkspecs/win32-g++" -o .objs\main.o main.cpp
In file included from D:/qt412/include/QtCore/qrect.h:1,
from D:/qt412/include/QtGui/../../src/gui/painting/qpaintdevice.h:28,
from D:/qt412/include/QtGui/qpaintdevice.h:1,
from D:/qt412/include/QtGui/../../src/gui/image/qpixmap.h:27,
from D:/qt412/include/QtGui/qpixmap.h:1,
from D:/qt412/include/QtGui/../../src/gui/image/qicon.h:29,
from D:/qt412/include/QtGui/qicon.h:1,
from D:/qt412/include/QtGui/../../src/gui/widgets/qabstractbutton.h:27,
from D:/qt412/include/QtGui/qabstractbutton.h:1,
from D:/qt412/include/QtGui/../../src/gui/widgets/qpushbutton.h:27,
from D:/qt412/include/QtGui/qpushbutton.h:1,
from main.cpp:3:
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:138: warning: inline function `bool operator==(const QRect&, const QRect&)' declared as dllimport: attribute ignored
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:139: warning: inline function `bool operator!=(const QRect&, const QRect&)' declared as dllimport: attribute ignored
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:166: warning: inline function `bool operator==(const QRect&, const QRect&)' declared as dllimport: attribute ignored
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:167: warning: inline function `bool operator!=(const QRect&, const QRect&)' declared as dllimport: attribute ignored
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:560: warning: inline function `bool operator==(const QRectF&, const QRectF&)' declared as dllimport: attribute ignored
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:561: warning: inline function `bool operator!=(const QRectF&, const QRectF&)' declared as dllimport: attribute ignored
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:573: warning: inline function `bool operator==(const QRectF&, const QRectF&)' declared as dllimport: attribute ignored
D:/qt412/include/QtCore/../../src/corelib/tools/qrect.h:574: warning: inline function `bool operator!=(const QRectF&, const QRectF&)' declared as dllimport: attribute ignored
In file included from D:/qt412/include/QtGui/qrgb.h:1,
from D:/qt412/include/QtGui/../../src/gui/painting/qcolor.h:27,
from D:/qt412/include/QtGui/qcolor.h:1,
from D:/qt412/include/QtGui/../../src/gui/image/qpixmap.h:28,
from D:/qt412/include/QtGui/qpixmap.h:1,
from D:/qt412/include/QtGui/../../src/gui/image/qicon.h:29,
from D:/qt412/include/QtGui/qicon.h:1,
from D:/qt412/include/QtGui/../../src/gui/widgets/qabstractbutton.h:27,
from D:/qt412/include/QtGui/qabstractbutton.h:1,
from D:/qt412/include/QtGui/../../src/gui/widgets/qpushbutton.h:27,
from D:/qt412/include/QtGui/qpushbutton.h:1,
from main.cpp:3:
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:36: warning: inline function `int qRed(QRgb)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:39: warning: inline function `int qGreen(QRgb)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:42: warning: inline function `int qBlue(QRgb)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:45: warning: inline function `int qAlpha(QRgb)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:48: warning: inline function `QRgb qRgb(int, int, int)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:51: warning: inline function `QRgb qRgba(int, int, int, int)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:54: warning: inline function `int qGray(int, int, int)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:57: warning: inline function `int qGray(QRgb)' declared as dllimport: attribute ignored
D:/qt412/include/QtGui/../../src/gui/painting/qrgb.h:60: warning: inline function `bool qIsGray(QRgb)' declared as dllimport: attribute ignored
g++ -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-s -Wl,-subsystem,windows -o "qtapp.exe" .objs\main.o -L"D:\MinGW\lib" -L"D:\Qt412\lib" -L"D:\qt412\lib" -lmingw32 -lqtmain -lQtGui4 -lQtCore4
mingw32-make.exe[1]: Leaving directory `D:/Devel/_projects/Qt/qt2'
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 17 warnings
Process terminated with status 0 (0 minutes, 18 seconds)
0 errors, 764 warnings
Is there anyway to link moc and uic? I went to the QTWorkBench options, but only found intermediate folders. This made me think that moc and uic ran by default (whenever necessary), but that doesn't seem to be the case b/c I get errors that are quelled when I run uic and moc manually from cmd.Depends on what your trying to do and how you want to handle ui files. If you want them to pass through the uic then just add them to your codeblocks project and they are added to your .pro file in the FORMS field.
Thanks, Brian.
the same code from above sampleSeems you 're not alone:
compiled with gcc 3.4.4 with warnings switch -W gives 764 warnings !!!CodeProcess terminated with status 0 (0 minutes, 18 seconds)
0 errors, 764 warnings
compiled with gcc 3.4.4 with warnings switch -Wall gives 0 warnings (as Yiannis said)
... for guy (like me) who do not have a ready to build Code::Blocks plugins environment (CB SDK + wxWidgets)....
...let's go for my first steps with subversion (cvs user)!when you once got familiar with svn, you'll be satisfied and probably you won't want use cvs again :)
P.S. Morten's .zip has exactly the same sources as the one in the first post with the major difference that Morten put it in the contrib plugins so it should be easier to build and integrade it with C::B. I'll also keep that approach from now onThat's right. If you could (in addition) follow the other plugins concerning the directory structure, too? Thus, have only one base folder with the sources and a single sub-folder for the resources. That would be great... (not pushing anything here, just trying to be consistent with other's work).
...I just wonder if it would be possible to add the QtWorkbench plugin to the contr. plugins. It seems that several users are interested in it and in Qt. IMHO it would be a nice addition to C::B and would solve the problem of a pre-compiled release...Yiannis has already shown that he has Qt development on his mind. Let's wait for the new compiler framework, this plugin might get obsolete. It could serve the users that need to use qmake for their projects or change to a RAD Qt plugin (I have some ideas but it would introduce Qt dependencies, we 'll see). Anyway Ephialtes will be afriend of Qt :)
That's right. If you could (in addition) follow the other plugins concerning the directory structure, too? Thus, have only one base folder with the sources and a single sub-folder for the resources. That would be great... (not pushing anything here, just trying to be consistent with other's work).I will, your solution has many advantages
...I just wonder if it would be possible to add the QtWorkbench plugin to the contr. plugins. It seems that several users are interested in it and in Qt. IMHO it would be a nice addition to C::B and would solve the problem of a pre-compiled release...Yiannis has already shown that he has Qt development on his mind. Let's wait for the new compiler framework, this plugin might get obsolete. It could serve the users that need to use qmake for their projects or change to a RAD Qt plugin (I have some ideas but it would introduce Qt dependencies, we 'll see). Anyway Ephialtes will be afriend of Qt :)
A better integration could be that it could be possible to open .pro file directly with C::B (I guess I dream to much...)File->Open->your.pro for now. It is possible and easy to have an option to edit the .pro file in the plugin and I will provide it. Just write your custom things outside the identifiers.
Another solution, could be (like decpp plugin) to have "import from .pro / export to .pro" options."Export" is possible (just needs another menu entry). Import is not at the moment (it would need a better parser than the one I already have).
Another quick alternative could be that we will be able to specify a .pro to the plugin and that he only manages SOURCES and HEADERS .pro entries according to file add/remove in C::B project. Other qmake options could be managed by hand (allow to use whole power of qmake). The plugin could be in charge to setup C::B (ie: add the pre-build command "qmake <custom.pro>" to generate the Makefile and check "use a existing makefile"). Thus we will be able to use C::B original "Build", "Clean" commands.This option as said above is only one menu entry away. You just have to decide what to provide to the plugin from the C::B envinroment and the rest of the stuff is up to you ;)
Working on a cross-platform IDE with Qt is crutial for me, so maybe (If you and my boss agree) I may contribute to this Qt integration.Gladly :) I 'm in the same place as you are (a cross-platform IDE with Qt is crutial for me). Believe it or not the requests have just started coming in, so stick around I 'll sure need your help (even using the plugin and posting what you think would be enough, if you are willing to get your hands dirty that's even better). Thanks for the sugestions.
Could you try again? New file (qtworkbench-0.4.1.alpha.zip) uploaded.Done that and it works again - thanks a lot!
If you now change the output DLL name (for Windows) from "qtworkbech" to "qtworkbench" it's perfect... ;-):lol: Nice catch! Uploaded qtworkbench-0.4.2.alpha.zip
What am I missing here? I got it built, but when I try to run QMake - Build, I get "mingw32-make.exe: *** No rule to make target `sub-Debug'. Stop."
EDIT: Never mind, I had my old makefile in the folder. Deleted it, and it builds. Yay. But when I set build mode to debug, it complains it can't find QtGuid4. Do I have to build Qt myself to get this?
EDIT2: Trying to rebuild results in "mingw32-make.exe: *** No rule to make target `cleansub-Debug'. Stop."
g++ -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -o "..\bin\Debug\CaveHackQt.exe" ..\obj\Debug\cavehackwindow.o ..\obj\Debug\main.o ..\obj\Debug\weaponEditor.o ..\obj\Debug\moc_cavehackwindow.o ..\obj\Debug\moc_weaponEditor.o -L"c:\MinGW\lib" -L"c:\Qt\4.1.4\lib" -L"c:\Qt\4.1.4\lib" -lQtCore4 -lQtGui4 -lQtGuid4 -lQtCored4
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lQtGuid4
EDIT2: Trying to rebuild results in "mingw32-make.exe: *** No rule to make target `cleansub-Debug'. Stop."Each of the targets you create must be in a seperate directory having the same name as the target. Not my fault, blame qmake ;) If you want to generate a debug build use the QMake Project Options menu entry. Another funny thing is that the generated "targets" in the Makefile are named sub-<actual target name>. Again not my fault, blame qmake.
No, it doesn't, you have to recompile Qt yourself in debug mode.
You should have a shortcut in "Start Menu" under Qt called "Qt 4.1.4 (Build Debug Libraries)".
My one contains this:
Starting dir: C:\Qt\4.1.4
Command: %COMSPEC% /k "C:\Qt\4.1.4\bin\qtvars.bat compile_debug"
I hope this helps... ;-)
EDIT2: Trying to rebuild results in "mingw32-make.exe: *** No rule to make target `cleansub-Debug'. Stop."Each of the targets you create must be in a seperate directory having the same name as the target. Not my fault, blame qmake ;) If you want to generate a debug build use the QMake Project Options menu entry. Another funny thing is that the generated "targets" in the Makefile are named sub-<actual target name>. Again not my fault, blame qmake.
I have Code::Blocks set to the standard "Debug" target. I am using the QtWorkbench -> QMake - Rebuild menu item, and Code::Blocks is giving me that message. Is something just screwed up with my system setup?QMake as I use it creates a "top level" .pro file with subdir entries that match your targets. QMake generated Makefiles do not provide (AFAIK) a clean target for the subdir targets. Secondly go to the make options tab of you codeblocks project (nothing to do with QtWorkbench) and see the make options, you'll see that for cleaning a target it has the command "make clean<target>" (no space between clean and target) and that causes the error you see. My suggestion is to change this to "make clean" (will rebuild all targets for your project).
Nice idea, but where is attachment from head post? I found only sources at http://tiwag.cb.googlepages.com/home, but binary…
...again (due to the API changes) this plugin is unfortunately broken. Any chance to get a new version?i had already a look on it, but i have to get familiar with the new API first ...
...again (due to the API changes) this plugin is unfortunately broken. Any chance to get a new version?I was planning a short trip in the weekend but I won't finally make it. So I guess I 'll have a look at it.
With regards, Morten.
//If the target is empty (it is for building the All virtual target), then get the first of the virtual
//target's actual and set the realTarget to it's name.
wxString realTarget = !target.IsEmpty() ? target : (m_SelectedTargets.GetCount() ? m_SelectedTargets[0] : _T(""));
m_BuildSelectedTargets = m_SelectedTargets;
m_BuildSelectedTargets.RemoveAt(0);
ProjectBuildTarget* bt = m_Project->GetBuildTarget(realTarget);
// bt is the first target of the virtual target's members.
if (UseMake(bt))
{
// make sure all project files are saved
if (m_Project && !m_Project->SaveAllFiles())
Manager::Get()->GetMessageManager()->Log(_("Could not save all files..."));
// gets the command for the first target of the virtual target
wxString cmd = GetMakeCommandFor(mcBuild, bt);
// Fire and forget, only the first target get's build :(
m_CommandQueue.Add(new CompilerCommand(cmd, wxEmptyString, m_Project, bt));
}
#Code::Blocks Identifier - START
QMAKE_CXXFLAGS+= -fexpensive-optimizations -O3 -w -W -Wall -pg -g -Wall -Wall -g
#Code::Blocks Identifier - END
<Build>
<Target title="Debug">
<Option output="Debug/hashphp.exe" />
<Option object_output="Debug/" />
<Option type="0" />
<Option compiler="gcc" />
<Compiler>
<Add option="-Wall" />
<Add option="-g" />
</Compiler>
<MakeCommands>
<Build command="$make -f $makefile $target" />
<CompileFile command="$make -f $makefile $file" />
<Clean command="$make -f $makefile clean$target" />
<DistClean command="$make -f $makefile distclean$target" />
</MakeCommands>
</Target>
<Target title="Release">
<Option output="Release/hashphp.exe" />
<Option object_output="Release/" />
<Option type="0" />
<Option compiler="gcc" />
<Compiler>
<Add option="-O2" />
</Compiler>
<Linker>
<Add option="-s" />
</Linker>
</Target>
</Build>
Do you accept patches? ;)Hi Cesar, nice to see you here :). I sure do accept patches :D The proposal to give commit access to the sources still stands to anyone intrested ;)
Give it a try, take a look at QIde (http://qide.free.fr). Its .pro files handling is amazing! I suppose we could use it, as QIde is GPL-ed as well ;)I have seen it and it is promising but it is quite imature yet. No doubt it has better handling of .pro files than C::B - QtWorkbench as it is built around them but a) I really need all the goodies that C::B provides and b) I need a generic IDE not a Qt based one. Sure most of my gui programming is around Qt (it's my job) but you also know that qmake / .pro files are restrictive. Right now C::B seems like the only C++ IDE that has the potential to become my main IDE both in linux and windows because it has more than average features (with more and more being added) coupled with its cross platform nature. The drawback is that I can't easily use Qt, but as it is with any oss: if like it and you miss a feature then add it, so that's what I did. This plugin started as strictly personal use but given that meny people were asking for Qt integration I released it and it has reached quite a few downloads (which is honestly surprising considering it's quality). That is what makes me want to improve it. Between wanting and actually doing comes my work and my personal life leaving me very little time to actually finish it. Anyway if you are intrested I 'll pm you my email.
Hi, I'm pretty new to programming and I would like to learn via Qt and Code::Blocks.
I'm trying to build the files for the Qtworkbench plugin, but I'm getting build errors, where it says that it can't find certain header files, such as
#include <sys/utsname.h>
#endif
#include <wx/tokenzr.h>
#include <sdk.h>
#include <settings.h>
#include <cbproject.h>
#include <compiler.h>
#include <wx/dir.h>
etc.
Sorry, I'm pretty green, but I'd appreciate the help. What am I doing wrong and how do I config Code::Blocks to load the files?
Thanks
Adam
:: === QtWorkbench, default ===
ld.exe:: cannot find -lcodeblocks
:: === Build finished: 1 errors, 1 warnings ===
:: === Code::Blocks, scintilla ===
ld.exe:: cannot find -lwxmsw28u
:: === Build finished: 1 errors, 0 warnings ===
soooooooooooo the wx variable is set to
base: ... wxWidgets-2.8.3
include: ... wxWidgets-2.8.3\include
lib: ... wxWidgets-2.8.3\lib\gcc_lib
(without the dots ;))
mingw32-make.exe: *** No rule to make target `cleansub-Debug'. Stop.
objReleasemain.o:main.cpp:(.text+0x68):: undefined reference to `vtable for MainWindow'
objReleasemain.o:main.cpp:(.text+0x6f):: undefined reference to `vtable for MainWindow'
objReleasemain.o:main.cpp:(.text+0xdf):: undefined reference to `MainWindow::staticMetaObject'
objReleasemain.o:main.cpp:(.text+0x17f):: undefined reference to `MainWindow::staticMetaObject'
objReleasemain.o:main.cpp:(.text+0x3c8):: undefined reference to `vtable for MainWindow'
objReleasemain.o:main.cpp:(.text+0x3cf):: undefined reference to `vtable for MainWindow'
objReleasemain.o:main.cpp:(.text+0x444):: undefined reference to `MainWindow::staticMetaObject'
objReleasemain.o:main.cpp:(.text+0x4ec):: undefined reference to `MainWindow::staticMetaObject'
objReleasemain.o:main.cpp:(.text+0x77e):: undefined reference to `vtable for MainWindow'
objReleasemain.o:main.cpp:(.text+0x785):: undefined reference to `vtable for MainWindow'
objReleasemain.o:main.cpp:(.text+0x7e1):: undefined reference to `vtable for MainWindow'
objReleasemain.o:main.cpp:(.text+0x7f5):: undefined reference to `vtable for MainWindow'
:: === Build finished: 12 errors, 0 warnings ===
[11:14:54.724]: ERROR: /home/mononofu/.codeblocks/share/codeblocks/plugins/libqtworkbench.so: not loaded (missing symbols?)Byo was reported with the same thing some time ago for wxSmith. I don't know how he solved this, I 'll ask when we get there :-)
[11:14:54.724]: ERROR: /home/mononofu/.codeblocks/share/codeblocks/plugins/libqtworkbench.so: not loaded (missing symbols?)Byo was reported with the same thing some time ago for wxSmith. I don't know how he solved this, I 'll ask when we get there :-)
If anyone feels like an early adopter, I have merged the branch I was working on to the trunk in the plugin svn.The page says:
# Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://qtworkbench.googlecode.com/svn/trunk/ qtworkbench
If anyone feels like an early adopter, I have merged the branch I was working on to the trunk in the plugin svn.The page says:Code...but this doesn't work for me...?! Am I missing something?!# Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://qtworkbench.googlecode.com/svn/trunk/ qtworkbench
With regards, Morten.
svn checkout http://qtworkbench.googlecode.com/svn/trunk/ qtworkbench
svn checkout http://qtworkbench.googlecode.com/svn/trunk qtworkbench
svn --version
svn, version 1.4.2 (r22196)
compiled Nov 3 2006, 16:53:07
Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
Morten, which svn client do you use? I have tried anonymous checkout with svn, rapidsvn and tortoise svn; all of them worked.It still doesn't work. I tried svn command line client and SmartSVN (Windows) - both fail with the same error message. :-(
:: === QtWorkbench, default ===
D:\CppDevelop\Eigene\QtWorkBench\src\qtworkbench.cpp:9: sdk.h: No such file or directory
D:\CppDevelop\Eigene\QtWorkBench\src\qtworkbench.cpp:10: annoyingdialog.h: No such file or directory
D:\CppDevelop\Eigene\wxWindows\include\wx\platform.h:196: wx/setup.h: No such file or directory
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:98: #error "wxUSE_DYNLIB_CLASS must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:106: #error "wxUSE_EXCEPTIONS must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:114: #error "wxUSE_FILESYSTEM must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:122: #error "wxUSE_FS_ARCHIVE must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:135: #error "wxUSE_DYNAMIC_LOADER must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:143: #error "wxUSE_LOG must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:151: #error "wxUSE_LONGLONG must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:159: #error "wxUSE_MIMETYPE must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:175: #error "wxUSE_PRINTF_POS_PARAMS must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:183: #error "wxUSE_PROTOCOL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:225: #error "wxUSE_REGEX must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:233: #error "wxUSE_STDPATHS must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:241: #error "wxUSE_XML must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:249: #error "wxUSE_SOCKETS must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:257: #error "wxUSE_STREAMS must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:265: #error "wxUSE_STOPWATCH must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:273: #error "wxUSE_TEXTBUFFER must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:281: #error "wxUSE_TEXTFILE must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:297: #error "wxUSE_URL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:305: #error "wxUSE_VARIANT must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:325: #error "wxUSE_ABOUTDLG must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:333: #error "wxUSE_ACCEL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:341: #error "wxUSE_ANIMATIONCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:349: #error "wxUSE_BITMAPCOMBOBOX must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:357: #error "wxUSE_BMPBUTTON must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:365: #error "wxUSE_BUTTON must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:373: #error "wxUSE_CALENDARCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:381: #error "wxUSE_CARET must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:389: #error "wxUSE_CHECKBOX must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:405: #error "wxUSE_CHOICE must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:413: #error "wxUSE_CHOICEBOOK must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:421: #error "wxUSE_CHOICEDLG must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:429: #error "wxUSE_CLIPBOARD must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:437: #error "wxUSE_COLLPANE must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:445: #error "wxUSE_COLOURDLG must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:453: #error "wxUSE_COLOURPICKERCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:461: #error "wxUSE_COMBOBOX must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:469: #error "wxUSE_COMBOCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:477: #error "wxUSE_DATAOBJ must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:485: #error "wxUSE_DATAVIEWCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:493: #error "wxUSE_DATEPICKCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:501: #error "wxUSE_DIRPICKERCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:509: #error "wxUSE_DISPLAY must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:517: #error "wxUSE_DOC_VIEW_ARCHITECTURE must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:525: #error "wxUSE_FILEDLG must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:533: #error "wxUSE_FILEPICKERCTRL must be defined."
D:\CppDevelop\Eigene\wxWindows\include\wx\chkconf.h:541: #error "wxUSE_FONTDLG must be defined."
:: More errors follow but not being shown.
:: Edit the max errors limit in compiler options...
:: === Build finished: 50 errors, 0 warnings ===
Anyways - a reason could be that I'm behind a firewall (but it's port 80...?!). I'll try again when I'm at home and report back if if works there... nothing to really worry about...Reporting back: It's working... ;-)
ld.exe:: cannot find -lwxmsw28u
:: === Build finished: 1 errors, 0 warnings ===
p.s.: compiling c::b gives me the same error, as in the past...You did not compile wxWidgets correctly or codeblocks can't find it.Codeld.exe:: cannot find -lwxmsw28u
:: === Build finished: 1 errors, 0 warnings ===
hi, i just wanted to say, that everything works fine, and your tutorials are working very good.
its just, that issue no. 7 is pissing me off :p
is there anything i can do? i mean, except copy pasting the line to console and insert the "" ?
1. What's the difference between choosing to create a release or a debug target when creating the project, I mean, does it matter, because later you can choose between both in the Qt Project options again?You get different compiler/linker flags generated from Code::Blocks and propogated to your Makefiles. For instance in "Release" targets you get -O2 in compiler options and -s in linker (optimize and strip respectively).
2. In the Qt Project options, it's irrelevant whether I select "Release" or "Debug" or both, when I build, it just does the one I' chosen when creating the project. Debug mode also only works if I've created a debug target, but the docs say "Also note that although we created a "Release" target when we created the project we can set our target to be a "Release" or "Debug" target from the Qt project options dialog."?This should not happen.
3. In the Create Targets Dialog (project creation), if I type in another name than "Release" (in the Release field) or "Debug" (in the Debug field), I can't compile because there "is no rule to make target ***" (*** = the name of the target). Why is this?This should not happen.
4. Something about makefiles: why does it always create both release and debug ones?This is the default behavior of qmake in windows. You get both files and depending on the entry in Qt project options the upper level Makefile decides which one to use. Anyway this is transparent and handled by qmake so there is nothing to worry about there.
...(because normally it searches for "makefile" and not for "makefile.targetname" [this isn't mentioned in the setting-up-a-project-tutorial?])...This is indeed documented in http://code.google.com/p/qtworkbench/wiki/QtWorkbenchProjects , there (check the screenshot) we change the Makefile that make tries to find to <whatever the Makefile name is>.<target>
I compiled the last version of plugin for the nightly build. But it doesn't work...Try removing "TIXML_USE_STL" from the compiler options (it's a define). This switch is obsolete for a long time now. Don't forget to re-build the plugin afterwards. Not build, but re-build.
It doesn't work too... CodeBlocks doesn't arrive to load the dll.I compiled the last version of plugin for the nightly build. But it doesn't work...Try removing "TIXML_USE_STL" from the compiler options (it's a define). This switch is obsolete for a long time now. Don't forget to re-build the plugin afterwards. Not build, but re-build.
I really like how this plugin is working so well, but I have one problem after following the wiki pages. My project gets this error when I try to build:
make.exe: *** No rule to make target `..\..\Qt\4.3.3\mkspecs\default\qmake.conf', needed by `Makefile.Debug'. Stop.
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings
I have problem with this plugin too...but I use new CB8.02.
I am wondering when will be released plugin to new CB...
So, why another plugin to obtain what apparently should be the same effect? Or, dually: if the need has been felt of implementing a new QT4 plugin, what does that default functionality, "File > New > Project > QT4 project", serve for?
Second point: is there any possibility of successfully compiling a QT4 application using the default
Codeblock's wizard option?
The default QT4 Project wizard just makes shure you have qt installed and if needed, asks you for its location. Nothing more, except for creating a nice little hello qt app with its main.cpp. If you wanna use the unique features Qt provides, ie. signals and slots, you have to run the files through the moc and if you're using the designer, you have to uic the .ui files first and import all those, or simply use qmake for the whole build process. Qtworkbench does all that for you, so you can compile inside of codeblocks without having to hassle with the build tools.
ui_*.h and moc_*.h files have no reason for being included in your project files as they are automatically generated. C::B provides facilities for performing custom compilation steps per file type and include them in your project files in order to participate to the build process. I haven't checked that yet but it seems that this could be another solution for building Qt projects and probably more "native" to the C::B build process. I think that if someone checks it out (http://wiki.codeblocks.org/index.php?title=Adding_support_for_non_C/C%2B%2B_files_to_the_build_system) and proposes things Yiannis will be more than happy to take a look at them. This facility was originally meant for adding support for non C++ files to the build process but it can evolve I guess.
I really like how this plugin is working so well, but I have one problem after following the wiki pages. My project gets this error when I try to build:
make.exe: *** No rule to make target `..\..\Qt\4.3.3\mkspecs\default\qmake.conf', needed by `Makefile.Debug'. Stop.
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings
Can you prepare a minimal project that reproduces this issue and upload it in the bug tracker?
Done.Thanks
The Code::Blocks project file of the qtWorkbench plugin doesn't correctly use the global variable "cb"
the search paths have the form
$(#cb)/include
$(#cb)/include/wxscintilla/include
but should look like this for greater compatibility
$(#cb.include)
$(#cb.include)/wxscintilla/include
...I have problem with this plugin too...but I use new CB8.02.
I am wondering when will be released plugin to new CB...
Shortly ;-)
LIBS += -L"E:\programs\devel\GnuWin32\bin" -L"E:\programs\lib\FTGL-2.1.2\win32_vcpp\Build" -lfreetype6 -lftgl_dynamic_MT
INCLUDEPATH += E:\programs\lib\FTGL-2.1.2\include E:\programs\devel\GnuWin32\include E:\programs\devel\GnuWin32\include\freetype2
INCPATH = -I'e:/programs/lib/qt/4.3.1/include/QtCore' -I'e:/programs/lib/qt/4.3.1/include/QtCore' -I'e:/programs/lib/qt/4.3.1/include/QtGui' -I'e:/programs/lib/qt/4.3.1/include/QtGui' -I'e:/programs/lib/qt/4.3.1/include/QtOpenGL' -I'e:/programs/lib/qt/4.3.1/include/QtOpenGL' -I'e:/programs/lib/qt/4.3.1/include/QtXml' -I'e:/programs/lib/qt/4.3.1/include/QtXml' -I'e:/programs/lib/qt/4.3.1/include' -I'e:/programs/lib/FTGL-2.1.2/include' -I'e:/programs/devel/GnuWin32/include' -I'e:/programs/devel/GnuWin32/include/freetype2' -I'e:/programs/lib/qt/4.3.1/include/ActiveQt' -I'debug' -I'.' -I'e:/programs/lib/qt/4.3.1/mkspecs/default'
LIBS = -L'e:/programs/lib/qt/4.3.1/lib' -lopengl32 -lglu32 -lgdi32 -luser32 -LE:\programs\devel\GnuWin32\bin -LE:\programs\lib\FTGL-2.1.2\win32_vcpp\Build -lfreetype6 -lftgl_dynamic_MT -lQtXmld4 -lQtOpenGLd4 -lQtGuid4 -lQtCored4
wxString out = opts[x];
out.Replace(_T("\\"), _T("/"), true);
Makefile.ASDViewer.Release:15: *** unterminated variable reference. Stop.
INCLUDEPATH += E:\MinGW\include $(#ft.include) $(#ft.include)\freetyp2 $(#ftgl.include)
INCPATH = -I"..\..\..\lib\QT\4.4.0\include\QtCore"
-I"..\..\..\lib\QT\4.4.0\include\QtCore"
-I"..\..\..\lib\QT\4.4.0\include\QtGui"
-I"..\..\..\lib\QT\4.4.0\include\QtGui"
-I"..\..\..\lib\QT\4.4.0\include\QtOpenGL"
-I"..\..\..\lib\QT\4.4.0\include\QtOpenGL"
-I"..\..\..\lib\QT\4.4.0\include\QtXml"
-I"..\..\..\lib\QT\4.4.0\include\QtXml"
-I"..\..\..\lib\QT\4.4.0\include"
-I"..\..\..\MinGW\include"
-I"$("
-I"e:\lib\QT\4.4.0\include\ActiveQt"
-I"..\asdviewer\obj"
-I"..\asdviewer\obj"
-I"..\..\..\lib\QT\4.4.0\mkspecs\default"
http://code.google.com/p/qtworkbench/issues/list
!!!Are you all died!!!?
I don't see how this can help... Anyway thank you for the interest I am still alive and well.If you find the time: I have fixed two serious null pointer issues that happen if you do single file compilation and have it's root in this plugin. Find the patch attached...