[Development] Installing Qt5Config.cmake from the Qt repo?

[Stephen Kelly]

On Wednesday, November 02, 2011 15:40:43 Thiago Macieira wrote:
> On Wednesday, 2 de November de 2011 13:38:15 Stephen Kelly wrote:
> > > However, let me make a suggestion: use macros, not variables. We've
> > > run
> > > into this problem before in Qt 4 where CMake did not add the -D
> > > macros
> > > that qmake did and then some results were different (unit tests, for
> > > example).
> > 
> > I might be missing some context here. You're talking about building Qt
> > with -DSTRICT_ITERATORS or whatever, and then using cmake to build a
> > project with that Qt, but then it didn't automatically use the
> > -DSTRICT_ITERATORS itself? Or are you talking about something else
> > entirely?
> > 
> > Could you expand on the probelms you encountered?
> 
> QtTest depends on QT_GUI_LIB being defined or not and changes the class that
> it creates for QTEST_MAIN. In Qt 5, with three Application classes, this is
> going to be even more important.
> 
> If you link to a Qt module named Foo, you must do:
> 	-I$QTDIR/include/QtFoo -DQT_FOO_LIB
> 	-L$QTDIR/lib -lQtFoo
> 
> The -D option has been missing in CMake.

Nope. It's not missing. It's in the UseQt4.cmake file.

> ADD_DEFINITIONS(-DQT_${qt_module_def}_LIB)

I don't know how long it has been there, but years at least.

If I do:

find_package(Qt4 COMPONENTS QtCore QtTest)
include(${QT_USE_FILE})

Then I can compile tests that do not link to QtGui (and use QApplication etc).

If I do:

find_package(Qt4 COMPONENTS QtCore QtTest QtGui)
include(${QT_USE_FILE})

then my tests have to link to QtGui.

This does get in the way a bit when parts of a project require QtGui and tests 
do not, but this is behaviour of CMake-Qt4 macros.

Using something like qt5_add_module I posted before we can do better. The 
qt5_add_module macro I posted in my last email is better already.

> 
> > qt5_add_module could be implemented to do the public and private linking
> > per target. The cmake 2.8.7 syntax for that would be
> > 
> > target_link_libraries(mylib
> > 
> >   LINK_PUBLIC ${Qt5Declarative_LIBRARY}
> >   LINK_PRIVATE ${Qt5Xml_LIBRARY}
> > 
> > )
> 
> LIBRARY or LIBRARIES? 
> 
> I hate that CMake has this plural problem. Make *everything* plural, even
> when there's only one library. Or better yet, provide a macro to ease
> development -- the variables are to be used if some other framework cannot
> use the qt5_add_* macros.

Yes, there's always more room for consistency.

> QtDeclarative requires QtCore and QtGui.

Yes, but because there is a QtDeclarativeTargets file which knows that fact, I 
don't need to specify them in the target_link_libraries command.

> 
> > However, there is currently no way to add target specific include
> > directories (though it could probably be pushed along
> > http://www.cmake.org/pipermail/cmake/2007-June/014386.html)
> > 
> > But how does this solve any issues with -DAnything?
> 
> That's why I'm saying "don't use target_link_libraries".
> 

I don't understand what target_link_libraries has to do with -DQT_FOO_LIB, but 
I'll just assume it's a non-issue.

> > > Another benefit is that I don't have to remember to list which
> > > modules I want in find_target. They should be automatically
> > > gathered from the qt5_add_module commands -- like qmake.
> > 
> > In my current branch, this already works:
> > 
> > find_package(Qt5 COMPONENTS Declarative)
> > 
> > # Can now use Qt5Declarative Qt5Core and Qt5Gui.
> > # The dependencies are already found by Qt5Config.cmake.
> > 
> > So I think that's another 'Done'.
> 
> Duplicated work. If you change your code, you need to update two places:
> where you add the module and where you tell CMake to search for it. I'd
> like the tool to help me.

I don't understand. You don't like having two lines:

find_package(Qt5 COMPONENTS Widgets)
...
target_link_libraries(mylib ${Qt5Widgets_LIBRARIES})

but you want it to be one line:

qt5_add_module(mylib Widgets)

? Is that right? Is that solved by the macro I posted in the other email?

> 
> > > Unlike qmake, if I want to decide
> > > whether to add some code based on the presence or absence a
> > > dependency,
> > > then I'd verify some variables set by FindQt5.cmake.
> > 
> > s/FindQt5.cmake/Qt5Config.cmake/ I suppose.
> 
> Yes and no. Yes, the variables come from the config file. No, because I
> don't care where they come from or if they were detected. That's an
> implementation detail. What I care is that find_package(Qt5) sets the
> variables -- and CMake runs FindQt5.cmake if I do that.

Yes, I was just correcting your sentence. There is no FindQt5.cmake. There is 
to be a Qt5Config.cmake. But this issue is not important. Yes, it's an 
implementation detail that you don't need to care about.

> Something close to that, though the testing would be for e.g. QtWebKit.
> FindQt5.cmake would set the variables for all Qt 5 modules found, so I can
> enable/disable portions of my codebase depending on what was found.
> 
> What I don't disable becomes mandatory.
> 

So you want 

find_package(Qt5)

if (Qt5Webkit_FOUND)
  # Do something
endif()

instead of 

find_package(Qt5 COMPONENTS Webkit)

if (Qt5Webkit_FOUND)
  # Do something
endif()

? That means that Qt5Config.cmake needs a list of Qt5 modules. I have no 
problem with that, but Lars indicated he didn't like thatQt5Config.cmake would 
have knowledge of what Qt5 modules exist I think.

> > > The above is only missing a listing of headers so that
> > > qt5_add_module
> > > knows
> > > what to moc. I don't know how that is implemented these days
> > > (qmake's
> > > HEADERS += line).
> > 
> > The easiest way is set(CMAKE_AUTOMOC ON), which will work for Qt5 in
> > CMake 2.8.7 (cmake 2.8.6 checks for Qt4). Alex has more details:
> > 
> > http://blogs.kde.org/node/4495
> 
> How does it know which files are my headers? It needs to have a list
> somewhere, which needs to be given to the Qt5 macros. It cannot scan all .h
> in the directory because:
> 
> 1) some files may be somewhere else
> 2) some .h may not belong to this target, so their moc outputs shouldn't be
> linked to this target
> 3) some .h may not belong to any target at all, just legacy stuff we kept
> 4) some headers may not be named *.h

For odd cases you use the same mechanisms you used before cmake 2.8.6: 
qt4_wrap_cpp, qt4_generate_moc etc.

Thanks, 

-- 
Stephen Kelly <stephen at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111102/1df6aee3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111102/1df6aee3/attachment.sig>