Config files for frameworks (Was: KArchive for Qt4)

[Stephen Kelly]

Alexander Neundorf wrote:

> On Tuesday 18 December 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > Please have a look at the current solidConfig.cmake.in.
>> > This is mostly as I think it should be (the include-guard is still
>> > missing).
>> > 
>> > 
>> > solidConfig.cmake
>> > 
>> >   # solidConfig.cmake provides information about the installed solid
>> >   # library.
>> >  
>> >  #is supported solid_HAVE_UDev         - TRUE if device discovery via
>> >  udev #is supported solid_USE_UDisk2        - TRUE is udisk2 is used
>> >  instead of #udisk on UNIX systems
>> 
>> Why HAVE vs USE? It looks like USE_SYSTEM_UDisks2 would be appropriate?

Did you notice this?

>> 
>> Do any of these 'feature variables' affect the headers of solid? For
>> example with #defines?
> 
> 
> Some of these informations are stored also in config-solid.h (those which
> are needed for building I guess). The information whether udisk or udisk2
> is used is not stored in config-solid.h.
> 
> 
> If I was a developer using the installed solid library, at least in the
> case that something doesn't work as it should, I would be very interested
> in knowing which backends the installed version of solid is using.
> 
> I could use ldd to see what libraries it links against. But this may not
> work if it is dbus-based. I may start to search in the headers. Or we may
> record this information in the Config.cmake file

Yes, it probably makes sense currently.

>> 
>> >  set(solid_INSTALL_PREFIX "${PACKAGE_PREFIX_DIR}")
>> 
>> I still don't consider this useful in general.
>> 
>> >  set(solid_LIBRARY KF5::solid)  # is this one needed ?
>> 
>> No, I don't see why it would be.
> 
> The reason I put it there initially was for completeness, to have both the
> single libraries as well as the potentially multiple needed libraries for
> using. 

Then let's define completeness as not including *_LIBRARY variables (See 
also my points elsewhere about minimalism and maintenance).

> With imported targets, they should be the same.

We already know that we will create IMPORTED targets, so the *_LIBRARY 
variables are not-useful, not-needed and redundant, especially as the 
imported target itself is documented.

Thanks,

Steve.