Alexander Neundorf wrote: > On Tuesday 01 May 2012, Stephen Kelly wrote: >> Stephen Kelly wrote: >> > This avoids the 'double booking' problem[1], which I think might be >> > real, so I think it's a good idea to optimize the common case, but I >> > won't be too disappointed if it's not acceptable. >> >> [1] http://lists.qt-project.org/pipermail/development/2011- >> November/000258.html > > Ask different people and you get different answers, preferable all > containing the word "should". > > > I would ignore if Lars says doesn't like Qt5Config.cmake having knowledge > about the modules Qt5 consists of. > I don't see any problem with this, and it makes it very clear and explicit > what Qt5Config.cmake is for. > > I would also ignore Thiago saying "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." > This is not a problem. > In his example there is find_package(... XmlPatterns), so XmlPatterns is > searched. Very obvious behaviour. If the developer doesn't clean up > properly it's his problem. > > > Also, if Thiago thinks this is bad > find_package(Qt5 COMPONENTS Widgets) > ... > qt5_add_module(mylib Widgets) > > it is just his opinion
Yes. I'm saying that in this case I agree with him. > (...you remember his other comments). > I think this is the right way to do it. > Two commands, each one does one thing right. Orthogonal API. Also consider > the "Convenience trap" (http://doc.trolltech.com/qq/qq13-apis.html). > > Two commands for two different things: search a package, use a package. 'use a package' is also not just one thing already. It's 'link to the libraries in that package' and 'use the include_directories that the package says should be used' etc. Those things are automatically done with this new command. > > So, I don't see any need for automatically invoking find_package() from > some other command. Calling find_package() is something people should be > used to, it shouldn't be hard for them. Hiding it in some other commmands > IMO would be good maybe for the lazy programmers, but not for > maintainability. E.g. you have start deciding/explaining when to use > find_package() and when not. Long term it's easy: You should never use find_package except for cases where the package is unconventional and target_use_package doesn't work. That's the ideal situation from my pov anyway. I see you see it differently. We can keep my ideal in mind when prototyping anyway. I don't think this issue blocks prototyping of the rest. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
