RFC: suffix ".in" instead of ".cmake" for template files to substitution processing

[Friedrich W. H. Kossebau]

Hi,

[replies only to kde-devel at 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