On Wednesday, 2 de November de 2011 16:29:16 Stephen Kelly wrote: > > 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.
But we agreed that including that file when you have more than one target in your CMakeLists.txt is a bad idea. We need a way to set the includes, defines and link libraries per target. Also, is the file one per CMake build or is it for each directory? To take an example: KDE doesn't use the use-file, which means problems arise when compiling tests. If the use-file is the way to do it, then we should start doing that for KDE too. To be clear: I don't think that's the way. > > > 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. It has nothing to do, which is the problem. To link to a Qt module, you need to add include dirs, a define and a link library. So I'd rather have one command that does it right than have people write boilerplate (and get it wrong). > > 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? No. It's still two lines: find_packages(Qt5) ... qt5_add_module(mylib Widgets) But the information that I need QtWidgets is in one line only. Imagine a more complex project: find_packages(Qt5 COMPONENTS Core Gui Widgets XmlPatterns Test) ... qt5_add_mdoule(mylib Widgets) ... target_link_libraries(test1 mylib) qt5_add_modules(test1 Test) ... target_link_libraries(test2 mylib) qt5_add_mdoules(test2 Test XmlPatterns) This is version 1.0. Then I do some more work and I decide to use QXmlStreamReader in my second test. Since I don't need QtXmlPatterns anymore, I go to the last line, where I added the module, and make it require only QtTest. Since my system does have QtXmlPatterns, I don't realise that I left the XmlPatterns requirement in the find_package line. So now everyone needs to install this addon when compiling the tests even if nothing uses it. > 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 will need to add the macros :-) > 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. Which is why a FindQt5.cmake script can find and collect all installed addons. But I don't mind having to declare the *optional* packages, the ones that I will use conditionals on. What I don't want is to have to do the double- booking of the mandatory ones. > > 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. Then let's take the opportunity to correct the mistakes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development