[cmake-developers] Target usage requirements and conventions

[Alexander Neundorf]

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 (...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.

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.

Alex