On 29/10/2011, at 6:14 AM, <lars.kn...@nokia.com> <lars.kn...@nokia.com> wrote:
> > > On 10/28/11 5:11 PM, "ext Stephen Kelly" <stephen.ke...@kdab.com> wrote: > >> On Friday, October 28, 2011 16:24:08 Matt Williams wrote: >>> On 28 October 2011 14:44, <lars.kn...@nokia.com> wrote: >>>> >>>> I think that's reasonable in general. It's similar to what we do to >>>> support pkgconfig. I agree with Thiago's comment that this should be >>>> split and we should have one file per shared library. >>> >>> I think Stephen's suggestion of having one CMake file for all Qt >>> Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the >>> most sense, at least for specifying which QtEssential libraries to >>> build against. It is the way most CMake files like this are done and >>> is not dissimilar to how the existing FindQt4.cmake works. Whether we >>> have a separate CMake file for Qt Addons (whether a separate one for >>> each module of another combined one) becomes a separate issue. >> >> Yes, that should certainly work. The idea of one config file per library >> should also work: >> >> find_package(Qt5Core) >> find_package(Qt5Gui) >> find_package(Qt5Widgets) >> >> then the contents of Qt5Config would look something like (CMake code): >> >> foreach(_component Qt5_FIND_COMPONENTS) >> if (_component MATCHES QtCore) >> find_package(Qt5Core NOMODULE) >> endif() >> # ... etc >> endforeach() >> >> Regarding what Qt5Config should be able to find, I would say that it >> should be able to find QtWidgets, which is not an essential module, but >> an addon in Qt 5. >> >> I'll prototype it next week and see how it goes. > While I understand that there are plenty of benefits of the new, more modular structuring of Qt5, we need to know where to draw the line on expecting devs to deal with this. The most natural way to handle the finding of Qt5 packages is using the COMPONENTS keyword with find_package(), not to have to list each module in its own find_package() command. As Stephen proposed in one of his earlier posts, the following is definitely the more natural way to pull in Qt5: find_package(Qt5 COMPONENTS QtCore QtGui ...) This also has the advantage that the dependencies between modules is handled by the Qt5Config file that provides the Qt5 info (but see further below) rather than having to rely on every dev who wants to use Qt5 to also get the dependencies right and list individual find_package() commands in the correct order. > My request here is that we don't add anything to qtbase that references > stuff on top (e.g. xmlpatterns). Modules should stay (wellŠ rather: > become) fully self contained. > > I also think that in this case each module should on installation provide > the file required to support cmake as a build system. Ie. qtxmlpatterns > should install one file somewhere that then magically makes > find_package(Qt5XmlPatterns) work. > I agree that each module should provide its own *.cmake file upon installation. If that file is installed to a well-known location, that means you won't need to have a separate find_package() call for each module. Instead, you have a top level Qt5Config which searches that well-known location and which handles them as COMPONENTS for a single find_package(Qt5) call. The top level Qt5Config would not need to hard-code any names, since it would build up a list of known components from what it finds. The dependencies between modules would be handled by the components themselves, ie if A depends on B, then the *.cmake file for A would pull in the *.cmake for B automatically, etc. One down side of this, however, is that we'd then be expecting each module maintainer to look after the relevant *.cmake file for that module. I'm all for that, but maybe not every maintainer is keen on supporting CMake files? Just a thought.... -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
