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

[Harald Sitter]

On 04.01.21 08:21, Friedrich W. H. Kossebau wrote:
> 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.
Seems like useless policy making. There is no benefit to being
consistent and considering cmake upstream doesn't enforce a standard I
don't see why we should. If we end up changing this we might as well
deal with .hpp and .hxx and .cxx and what have you.

Changing this stuff generates noise in the repos I for one can do without.

HS