KDEInstallDirs variables

[Alex Merry]

On Monday 08 December 2014 23:52:16 Stephen Kelly wrote:
> Alex Merry wrote:
> > Does CMake even provide a way of marking variables as deprecated?
> 
> Nope. But you wrote below you don't want that anyway.

That's not quite what I said - in fact, if it were possible, I would probably 
do that.

> > Simply
> > making the old name an alias for the new doesn't quite work, as we need to
> > maintain compatibility on the command line as well as in the CMakeLists
> > files.
> 
> Why don't you issue a message if the variable is set on the command line?
> Deprecated means command lines should be updated, right?

Because I hadn't thought about doing that :-)

> Why did you deprecate variables which are widely in favor of new variables
> without porting even the most core framework kcoreaddons (eg
> CMAKECONFIG_INSTALL_PREFIX variable)?

I can't really remember now. I think it was a combination of the transition 
not being high priority, and - if I'm being honest with myself - a certain 
amount of ambivalence about the transition. Which leaves two different 
impressions about what to use from reading KF5 source or reading the ecm docs 
- not ideal.

> There is deprecation documented, but no deprecation message, and I doubt
> there's widespread knowledge of a need to migrate eg packaging scripts away
> from old variables to new ones. Is there such a need? Is there a migration
> need or plan?

As you've pointed out (indirectly, at least), the current situation is not 
great. It should go one way or the other.

> >>  * You shouldn't use the CMAKE_ prefix for the same reason you don't
> >>  prefix
> >> 
> >> Qt classes with 'Q'. That namespace should be considered owned by cmake.
> >> 
> >>  * The file contains variables with at least prefixes CMAKE_, KF5_, and
> >> 
> >> KDE_. Consider using KF5_ universally.
> > 
> > Hum. I went for that to try to make it at least partially interchangable
> > with GNUInstallDirs.cmake. Perhaps that wasn't such a bright idea - at
> > least, I should maybe have made the ones that *don't* appear in
> > GNUInstallDirs have a different prefix.
> > 
> > I agree that the variables are a bit of a mess. It's... well, not the
> > approach I would have taken if I had started less close to the source
> > compatibility cut-off date for KF5.
> 
> Do you see all/any of this as something to need to fix?

Well, I can't remove any of the existing CMAKE_* variables without risking 
breaking stuff. So, while using CMAKE_INSTALL_* for things that aren't in 
GNUInstallDirs may not be ideal, I think it's not worth trying to backpedal on 
that (although I may want to revisit that for KF6/e-c-m2, whenever that may 
happen).

I think the right plan is to:
* port KF5 to use CMAKE_INSTALL_* variables
* warn about using the old variables on the command line
* when KF6 and/or e-c-m 2.0 happens (whether or not those happen in sync),
** ditch the old variable names
** use a KDE_INSTALL_* prefix for all variables
** keep the CMAKE_INSTALL_* versions of the variables, but deprecate their use 
in CMakeLists files, and deprecate the use of any that aren't in GNUInstallDirs 
on the command line

This avoids having two levels of deprecated variables, and the second 
migration should be pretty painless (a pretty simple sed should do it).

Any feedback on that (from the list in general, not just Stephen)?

Alex


PS: thanks for the push: I really shouldn't have left that job half-completed 
for so long