KDEInstallDirs variables
Stephen Kelly
steveire at gmail.com
Mon Dec 8 22:52:16 UTC 2014
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.
> 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?
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)?
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?
>> * 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?
Thanks,
Steve.
More information about the Kde-buildsystem
mailing list