Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
QtWorkbench plugin
Methedrine:
First of all, great work there yop! I really like this integration, it eases managing Qt's .pro files by miles :D
However, I am a bit surprised by the QMAKE_CXXFLAGS put into the Debug.pro from your tool. My compiler settings in Code::Blocks for the Debug target are -g and -Wall, yet the Debug.pro file states the following:
--- Code: ---#Code::Blocks Identifier - START
QMAKE_CXXFLAGS+= -fexpensive-optimizations -O3 -w -W -Wall -pg -g -Wall -Wall -g
#Code::Blocks Identifier - END
--- End code ---
That does not look quite correct with repeating several flags and expensive optimizations for a debug version :wink:
yop:
Hi Methedrine thanks for your nice words. I am always surprised by the number of people that found the plugin usefull, I never expected that :D
Anyway could you please take a look to your codeblocks project file ([project name].cbp) to see if these g++ flags are also there? The plugin takes the flags directly as a wxArrayString from the c::b sdk. The duplicate entries could happen if you have the same flags in your compiler options and the project build options (now that I think about it I can fix that easily, typical case of lazy programmer :lol:).
Since you 're using the plugin what do you think about my suggestions in my previous post?
Methedrine:
Hi yop,
I just had a look at my .cpb file and there are not the symbols written into the .pro file - see for yourself:
--- Code: (xml) ---<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>
--- End code ---
Personally I'd love to see qtworkbench menu being removed and the usual compiler interface being used instead. It's just due to some lazyness on my side though (I love simply hitting F5 to start compiling and debugging :P)
Also, moving the Qmake options into the project properties dialog is probably the best thing, but moving them into the project menu is definately a good start!
Cesar:
Greetings, yop.
First of all I'd like to thank you for this piece of work you've already done to move C::B towards Qt integration!
Unfortunately it couldn't create *.pro file for me because of lack Release and Debug directories in the project tree. But if I create them manually it seems to work :)
Do you accept patches? ;)
yop:
--- Quote from: Cesar on September 30, 2006, 07:16:53 pm ---Do you accept patches? ;)
--- End quote ---
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 ;)
I am working towards a different integration (see previous posts) that will use some lexical analysis tool (I 'm learning my way with antlr, Takeshi Miya praises it all the time so I thought I 'd give it a try) to parse .pro files and get rid of the identifiers (ugly but it did the trick). This way we could also import Qt projects to code::blocks. Anyway I know you have the will to help towards a Qt friendly IDE and code::blocks is a feature rich IDE but doesn't really like Qt (yet). Untill now I 'm the only one who gave it a shot and the results are far from satisfactory but pretty popular, which means that there are people out there looking for an IDE with Qt integration (I 'd say more on windows as in Linux KDevelop is difficult to beat regarding Qt development). Anyway I 'll be glad to hear from you again.
P.S. Regarding the not creating the .pro issue, the targets in c::b project are not the same thing as qmake targets so I had no choice other than using the qmake approach (SUBDIRS) but that means that for each of your targets you must have the respective directory.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version