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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
