libexec (Re: "kde5" or "kf5" ?)

[David Faure]

On Friday 22 February 2013 19:29:48 Alexander Neundorf wrote:
> On Friday 22 February 2013, David Faure wrote:
> > How about we make it
> > CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/libexec/kioslave"?
> > Then on Windows, we can just request that PATH contains that (unique)
> > libexec directory, and we have achieved our goals: relocatability
> > (assuming that word exists :) ).
> 
> This is a question I've been pondering for a while: while on Windows we
> definitely need to be relocatable, how useful in reality is this when RPATH
> is involved ?
> 
> If I move libraries which have interdependencies from one custom location to
> another custom location, their RPATH will be wrong.

Well, if you move libs, you can also set LD_LIBRARY_PATH, problem solved.
RPATH is just convenience for not having to set LD_LIBRARY_PATH.

> But being able to able to install a binary package in different prefixes
> would be a nice thing. RPATH *can* be solved by using $ORIGIN. It would be
> nice if we could detect that from within.
> It is actually more or less necessary to make it possible to distribute
> custom binary packages.
> I love how I can unpack the cmake binary packages from Kitware just anywhere
> and they work (for cmake it's easier, it's an executable).

I guess what you're saying is that moving stuff is also nice on Unix, not only 
on Windows. I'm not convinced it's that useful (and BTW, ever tried moving Qt? 
Might work for end users, but definitely not for developers), but anyway, if we 
have to make it work for Windows, it'll work on Unix too.

> > > The (to be) installed kioConfig.cmake can also determine its own
> > > location and the location e.g. of kioslave at runtime.
> > 
> > That sounds like compile-time, not runtime.
> 
> Well, compile-time for the using project, not compile-time of the used
> project.
> For the used project Foo, it is at runtime of the FooConfig.cmake file, it
> can query where it is located, check whether this is the original install
> location, and react to that.

I'm afraid you lost me there.

> > > Or a KIODIRS env.var. ?
> > > (basically: do we need those things we had for kdelibs now once for each
> > > library ?)
> > 
> > This sounds like extremely cumbersome setup. We have enough env vars to
> > set already, I would really like to avoid having to require more.
> > Especially
> 
> Yes, but isn't this what we are in for with getting rid of KDEDIRS/KF5DIRS,
> i.e. *fully* independent libraries ?

Well, one-env-var-per-framework would lead to 20 env vars, in addition to the 
standard ones (XDG_* etc). Surely we can do without the 20 env vars, and still 
have fully independent libs... I don't follow your reasoning here.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks