Config files for frameworks (Was: KArchive for Qt4)

[Stephen Kelly]

Alexander Neundorf wrote:
> At work, we set the RPATH manually. We know the limited number of
> libraries we link against, we want to have full control over the RPATH. I
> would be surprised if we would be the only ones.

Anyone handling RPATH manually knows about get_filename_component :).

> 
> I wouldn't even say using INSTALL_RPATH_USE_LINK_PATH is better or more
> modern, it's IMO just more convenient for a big project as KDE is.

Ok. Still though, we're not making your usecase hard. 

If we really find that it's so common that we should add it to all Config 
files, we can do that in any release. We can't remove it even if we find 
that there's divergence among the Config files and the way the _LIBRARY_DIR 
variable is calculated. We'd have no choice but to maintain them.

Let's please minimise instead. No one is going to decide not to use Solid 
over something like this.

> Having said that, I now consider them simple libraries, like qwt or qxt,
> which, if LGPL would not be a problem for us at work, we could simply use
> like any other library. I would be happy then if the library would provide
> me a karchive_LIBRARY_DIR variable, which I can use for the RPATH or not.

If you create a FindKArchive.cmake, as you likely would, you could calculate 
the _LIBRARY_DIR there.

> ... ok, actually, we set the RPATH fix to a location inside our install
> hierarchy, ignoring any other directories.
> 
> Another option would be to have
> 
> get_target_property(_tmpSolidLocation KF5::solid LOCATION)
> get_filename_component(solid_LIB_DIR ${_tmpSolidLocation} PATH)
> 
> in solidConfig.cmake.

Or FindSolid.cmake, iff you do manual RPATH handling.

This is what I meant by 'calculation' when I wrote it above, and that's why 
I call solid_LIB_DIR a pre-calculated variable in your snippet - The user 
can calculate it, but we would be pre-calculating it for them in the config 
file, whether they need it or not.

Let the user calculate it if they want it.

> This way it wouldn't look like pre-calculated variables.
> But, actually if you look into the Targets-<buildtype>.cmake file,
> _IMPORT_PREFIX is also precalculated based on information from cmake time.
> So practically, it wouldn't change much.

The difference is that Targets-<buildtype>.cmake are auto-generated, not 
hand-maintained, and the _IMPORT_PREFIX is a non-public, temporary variable 
which is set to null at the end.

To be clear - my problem is with the maintenance cost. I don't have a 
problem with calculating things in general. I do want to encourage DRY and 
KISS though. 

I'm also concerned with the effort required for a newbie to understand why 
each line of a Config file exists.  Without reading this thread, I don't 
know how they would know why solid_LIBRARY_DIR is defined, but not used 
anywhere in KDE etc etc.

I know that for me, cmake use in KDE was hugely mysterious for a long time 
because I didn't know what things did, and why things were 'just set' like 
that. If we minimise the code in absolute terms, there's less to introduce 
confusion.

> 
> I mean, why should we not provide it ?

Because we'll have to maintain anything that we provide. Keep it simple. 
Keep it readable and understandable.

> We depend on that the information we have in the Config.cmake file is
> correct. If we are afraid that our calculated solid_LIB_DIR is wrong, then
> we have a bigger problem.

Once something exists, people start using it for things it wasn't initially 
intended for. Then they find reasons to extend the original features, but 
only extend one or two of the files, so suddenly we're all out of sync.

I don't suspect that any calculated solid_LIB_DIR is wrong. I just don't 
want to have to maintain more than is really known to be needed, necessary, 
required and valuable-to-most-users, not just convenient-for-some-users.

That's why I keep asking to minimise.

Thanks,

Steve.