I have a large project, relies on GNU automake, want to add QT components, must I use qmake for everything now?

I have a large software project which uses aspects of OpenGL for visualisation. I want to add a GUI and was thinking of using QT. Now from what I understand, building QT stuff can get ugly unless one sticks to using the qmake command...

However, my project relies on the GNU tools for building (g++, autoconf, automake, etc., etc.). Must I therefor开发者_开发百科e restructure my whole build process to use qmake just so that I can use a few small aspects of QT? I am very reluctant to do so given the size of the project.

As a thought, could I possibly (somehow) use qmake for the graphical components (i.e. qt-dependent stuff) only and continue to use my standard GNU build process (make, g++ etc.) for everything else?

Thanks, Ben.

A quick Google search turned up AutoTroll and a howto.

Personally, I have used Qt without qmake before, but it was for a personal project, so I just used a (non-portable) Makefile. I set a variable (QT4DIR, since QTDIR was used by Qt3) to point to where I installed Qt, then added -L$(QT4DIR)/lib -lQtCore -lQtGui, etc. to LDFLAGS and -I$(QT4DIR)/include/QtCore, -I$(QT4DIR)/include/QtGui, etc. to CXXFLAGS. It looks like those links explain how to do something similar for autotools.

Edit:

To handle the MOC, I've added implicit rules like:

 moc_%.cc: %.h
     $(MOC) $< -o $@

And then make sure that all required moc_*.cc files are included in my SOURCES. It's a bit of a pain to specify QObject-derived classes twice, but everything will get built.

After much head-scratching, I decided to compile the original code into a library using my original build process (but slightly modified to compile a library rather than a binary) and then compile the gui separately using qmake. This would then also link the gui in with the original library code. Not 100% ideal but works fine. Probably the biggest hurdle was converting some glut code into a QGLWidget...