[CMake] Patch to FindQt4.cmake for supporting moc compiler options

[Miguel A. Figueroa-Villanueva]

Hello,

I just saw the CMake native command qt_wrap_cpp in cmQTWrapCPPCommand.h.

Why would there be a command like this and a macro in FindQt4
(QT4_WRAP_CPP)? Which is the correct one to use?

I think that these commands might obsolete the patch in this thread
and it should rather be supported in the cmake command.

Alex, have you thought of supporting options in the qt_wrap_cpp
commands? What interface would you expect? As indicated below I
encountered the need to pass definitions to the moc compiler and
thought that the following interface would be useful:

QT4_WRAP_CPP(<outputfiles> <moc-sources> [OPTIONS opt1 opt2 ...])

so that I could do:

QT4_WRAP_CPP(sources ${moc-sources} OPTIONS -DMYDEF)

I guess this could be applied to the qt_wrap_cpp command...

Comments?

--Miguel

On 11/27/07, Miguel A. Figueroa-Villanueva wrote:
> On 11/27/07, clinton wrote:
> > On Saturday 24 November 2007 3:23:16 pm Miguel A. Figueroa-Villanueva wrote:
> > > Hello,
> > >
> > > I would like to propose the following patch or something similar to
> > > add support for moc compiler options. Currently, one can do the
> > > following:
> > >
> > > SET(moc-sources foo.h bar.h)
> > > QT4_WRAP_CPP(sources ${moc-sources})
> > >
> > > With the attached patch one could pass also options to be invoked with
> > > each moc-source:
> > >
> > > QT4_WRAP_CPP(sources ${moc-sources} OPTIONS -DMYDEF)
> > >
> > > The current approach is a simplified one to support the following syntax:
> > >
> > > QT4_WRAP_CPP(<outputfiles> <moc-sources> [OPTIONS opt1 opt2 ...])
> > >
> > > This could also be applied to QT4_WRAP_UI(...).
> > >
> > > --Miguel
> >
> > I'm curious what the convention is for adding arguments to custom commands in
> > macros.
>
> Don't know... But I looked at how cmake commands work and tried to
> provide something along those lines.
>
> > To compare, I see the FindSWIG.cmake/UseSWIG.cmake allow setting the
> > CMAKE_SWIG_FLAGS variable.  The advantage of that is that it applies to all
> > calls of the macro.
>
> The problem I see with this is that you depend on the value of say
> QT4_MOC_FLAGS and then scoping issues come into play. For example, if
> you set this flag then in a later call you will have it affect that
> call unintentionally unless you clear it. It's then complicated when
> you consider INCLUDE files. So, my thoughts were to send the options
> to the macro every time you need them and not worry about the variable
> scope ramifications and other use cases.
>
> Just my two cents,
> --Miguel