[cmake-developers] Target usage requirements and conventions

[Stephen Kelly]

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.