KDEInstallDirs variables

[David Faure]

On Tuesday 30 December 2014 14:08:44 Alexander Neundorf wrote:
> On Sunday, December 28, 2014 13:39:47 David Faure wrote:
> > On Wednesday 10 December 2014 12:49:45 Alexander Neundorf wrote:
> > > On Tuesday, December 09, 2014 21:40:28 Alex Merry wrote:
> > > > On Tuesday 09 December 2014 21:32:28 Stephen Kelly wrote:
> > > > > Alex Merry wrote:
> > > > > > Actually, having thought about it a bit more (that's what my
> > > > > > commute
> > > > > 
> > > > > > to work's for, right?):
> > > > > Yes, this is better.
> > > > > 
> > > > > > * add KDE_INSTALL_* variables, and document them as the
> > > > > > recommended
> > > > > 
> > > > > Not KF5_? I didn't think long about it so I don't know which is
> > > > > better.
> > > > 
> > > > Nope, KDE_. The variables that are KF5-specific already have a 5 in
> > > > the
> > > > name.
> > > > 
> > > > As a bonus, having KDE_INSTALL_* variables come from
> > > > KDEInstallDirs.cmake
> > > > should make it easier for people reading CMakeLists.txt files of KDE
> > > > projects.
> > 
> > Sounds good to me.
> > 
> > > Another option would be to upstream KDEInstallDirs.cmake into cmake,
> > > then
> > > the CMAKE_ prefix would be Ok, and the two files
> > > (GNU|KDEInstallDirs.cmake)
> > > should actually follow the same guidelines.
> > 
> > Would that even be accepted into cmake?
> 
> you never know before trying it.

Those who have experience with that, might have an idea of what has some 
chances and what doesn't :-)

Trying something that we know is deemed to fail, is just a waste of time.

> > It would force requiring very-latest cmake, too.
> 
> I had the impression that's the current policy anyway: do everything
> directly in cmake and depend on the latest version.

All of KF5 still works with cmake 2.8.12, so this is definitely not the case 
(anymore).

> > Unless we wait for a long
> > time before porting to that new cmake module - but then it better not have
> > the same name as the one in ECM, otherwise the wrong one will be picked up
> > for some people...
> > 
> > At this point it seems this suggestion stalled progress completely, since
> > that's a whole other direction to take, with many more complications and
> > an uncertain outcome...
> 
> Sorry for making a suggestion...

No harm done, I wasn't blaming you, just assessing what seemed to be the 
current situation ;) Turns out I was wrong though, I had overlooked the 
related reviewboard request, sorry about that.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5