Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: alu on July 28, 2005, 06:13:38 am

Title: Help needed to develop Qt plugin
Post by: alu on July 28, 2005, 06:13:38 am
Hi guys,

I want to make a Qt plugin.  I think that the plugin system in C::B is really slick and I'm hoping you guys might have some tips for some problems I'm having.

To start, this is the functionality I want to create:

  1. If you right-click on a header in your project tree you can mark the header "To be moc'd"

  2. For every header that is marked "to be moc'd" a couple build rules have to be added to the project.  Let's say the header was "something.h", then just for demonstration purposes, here are some makefile-style build rules that need to be added:

   moc_something.cpp: something.h
      $(MOC) something.h -o moc_something.cpp
   
   moc_something.o: moc_something.cpp
      $(CPP) $(all the standard flags here) moc_something.cpp -o moc_something.o

   And then of course moc_something.o has to be list of object files linked with the app.

This is just one of the features that I want to implement in this plugin.  How should I tackle this problem?  Should this be added as a custom build command for something.h?  (BTW I noticed that even if you take away the <Option compile="0"/> for the something.h header in your .cbp project file, C::B decides to add it back in when you save the project for some reason.  No difference if I put <Option compile="1"/>.  I'll have to track down the bit of code responsible for this.)

Or would it be better to make both the moc_something.cpp a separat file <Unit> in the project.  I'd prefer it not to be listed in the project tree though. 

When playing with custom build commands for something.h in the "Advanced", the "Object file:" option is greyed out and the only option is something.o, is there any reason why I can't change this?

======

I was thinking that another option would be to make my plugin a compiler plugin.  It would intercept compile-commands and then:  1) go through all the headers in the project, 2) if it finds one marked "to be moc'd" (maybe something like <Option to_be_mocd="1"/>) it will build both moc_{header}.cpp and then moc_{header}.o 3) all the moc objects could be built into a static library "moclib.a".   After all those steps are done, the regular compiler plugin could take over and handle all the normal <Unit>s as it does normally.  The project would have to have the "moclib.a" library added to the final link stage.

Would this option work at all?  Is it possible to have two compiler plugins active at the same time? (my initial tests indicate that the answer is No  - the compile callbacks in my custom compiler plugin were not getting called)

Believe it or not, this post was shortened a lot, I want to tackle one problem at a time, and I think this is the hardest one.  I'd appreciate if you guys could give me any hints at all on this. 

Thanks in advance,
Alex
Title: Re: Help needed to develop Qt plugin
Post by: Urxae on July 28, 2005, 10:30:29 am
IIRC, the compiler plugin system is going to get an overhaul for version 2, as it's a bit messy at the moment. Currently there's only one compiler plugin that handles all compilers, which works but isn't ideal. The plan is to separate the compilers into different plugins. I think your idea will work better when this is done, as you could write your meta-compiler as a separate plugin as well, but with a pointer to a 'real' compiler plugin which it uses to do the actual compiling.

Of course, this is all from memory and I could be terribly wrong about the compiler plugin system and what'll happen to it. I'm not really 'in the loop' on that. But I'm sure Yiannis could tell you more, according to my limited knowledge of the system he's the only one ever to do any serious work on it.
Title: Re: Help needed to develop Qt plugin
Post by: alu on July 29, 2005, 06:17:26 am
OK, thanks for the heads up on the version 2 overhaul.

Question is, since version 2 is some time away, does anyone have suggestions for me?  Even if it involves some ugly hacks, I'll be willing to do it for the time being until a more elegant solution is possible.
Title: Re: Help needed to develop Qt plugin
Post by: zieQ on July 29, 2005, 11:45:16 am
IIRC, the compiler plugin system is going to get an overhaul for version 2, as it's a bit messy at the moment. Currently there's only one compiler plugin that handles all compilers, which works but isn't ideal. The plan is to separate the compilers into different plugins. I think your idea will work better when this is done, as you could write your meta-compiler as a separate plugin as well, but with a pointer to a 'real' compiler plugin which it uses to do the actual compiling.

What about compiler/linker options conversion from compiler to compiler? Something is planned or it will be the responsibility of the programmer to set the options correctly for each compiler?
Title: Re: Help needed to develop Qt plugin
Post by: alu on August 03, 2005, 06:58:10 am
bump...
hmmm no suggestions at all?
Title: Re: Help needed to develop Qt plugin
Post by: yop on November 24, 2005, 09:45:47 am
OK let  me give you some info on my work with a qt plug in.
Firstly I must say that it is based on a patch I did (pretty sloppy I must admit) to the compiler plugin. I added another option to the build methods under invoke compiler directly, use Makefile I added Use Qmake. When that option was selected I took over the build process, created a custom .pro file and built from that one.
Having the "experience" of patching the compiler plugin, I decided to wrap it up in a plugin.
My thoughts were:
1st phase: Compile qt projects correctly (with .ui files if present, images, resources everything) using every useful feature of codeblocks I could (projects are perfectly organized, gives you a lot of power) and integrate with the rest of the program (should be able to debug change compilers etc. etc.)
2nd phase: Rest of the tools: qtdesigner, translator :)
The whole thing will be something like a full Qt Workbench (well that's what my plugin is named :)). It will be implemented as a compiler plugin as I think this would be a cleaner way to achieve the above. Your way is more transparent and less powerfull but of great usability and can be implemented much faster.
Anyway I think that we could join forces on this one ;)