Hi,
[replies only to kde-devel@kde.org, please]
tl;dr This is a proposal to standardize on the suffix ".in" for input/
template files passed to cmake's configure_file() in KDE projects.
When it comes to naming the files used as templates for build-time generation
of source/data files by substitution processing, by calling cmake's
configure_file() or configure_package_config_file(), there are currently two
traditions/cultures alive in KDE:
* using the suffix ".in"
* using the suffix ".cmake"
Why is it like that I have some theories, but just stating the current reality
here.
While having not too strict policies about how active developers manage their
sources is usually a better thing IMHO, I personally favour per-product
consistency only, in the case of input/template files though it can affect
things outside of a single project/repository, like with files which are
processed by the global KDE translation system:
As we discovered the last days, "scripty" (the nightly KDE translation system
bot that synchronizes between source repositories and the database repo of the
translators) was only instructed to handle ".desktop.cmake" files, and thus
ignored the ".desktop.in" ones.
While scripty last night now has been instructed to also start to care for the
".in" variant, having two different options adds some complexity and allows
some confusion for people looking at such files ("why once .cmake and once
.in? Is there a difference?"). And besides personal preference so far no real
argument for being able to choose a suffix was told.
So given that and first comments on the matter mostly in similar directions, I
propose to have some global KDE standard on the suffix of such input/template
files, and once decided, also convert existing files to that suffix, so people
do not revive the deprecated suffix culture due to innocent copy & paste :)
And the proposal is to use ".in".
Pros:
* ".in" can be seen used as suffix with examples in documentation of at least
autotools, cmake, qmake & scons for input files to substitution processing,
and as result can be also found in many projects using those buildsystems. So
people switching between projects or new to KDE do not have to relearn or
switch their mindset
* ".in" is shorter :)
* ".cmake" is the suffix to denote CMake code files usually, including the
CMake config files (which are partially also generated from template files, so
such would be named FooConfig.cmake.cmake, which at least looks strange),
overloading the meaning of the suffix makes things a bit less clear
* [please fill in]
Cons:
* some substitution markup is cmake-specific, like #cmakedefine, so projects
trying to support multiple build systems would like to specify the cmake-
variant filetype some more (not aware of that need in KDE projects currently)
* [please fill in]
Your comments, please.
If there seems consensus and no objections have come up until Monday, Feb.
1st, I would then start to get us moved in that direction, unless we move
already ourselves then :)
Cheers
Friedrich
