User forums > General (but related to Code::Blocks)

Help needed to develop Qt plugin

(1/2) > >>

alu:
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

Urxae:
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.

alu:
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.

zieQ:

--- Quote from: 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.
--- End quote ---

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?

alu:
bump...
hmmm no suggestions at all?

Navigation

[0] Message Index

[#] Next page

Go to full version