Standard for placing any template Find-modules with the original lib? (was: Re: Strange commit to FindKDE4Internal.cmake)

[Friedrich W. H. Kossebau]

Am Freitag, 17. Februar 2012, 19:34:38 schrieb Alexander Neundorf:
> On Friday 17 February 2012, Friedrich W. H. Kossebau wrote:
> > Am Freitag, 17. Februar 2012, 17:33:34 schrieb Alexander Neundorf:
> > > A library must never install the Find-module for itself.
> > > 
> > > This defeats the purpose. This is like putting the remote control right
> > > next to the TV, or the treasure map right into the treasure chest. You
> > > don't know where the plan is, but once you found the plan, you already
> > > found what you are interested in and don't need the plan anymore.
> > 
> > That reminds me of something I wanted to ask for a while:
> > 
> > A few libraries provide in their sources a template for the Find-module
> > for
> > itselves, as a nice starting point for devs using the lib and needing that
> > Find-module.
> > 
> > But IIRC those libs had the template file in the same "cmake/modules"
> > subdir where also the normal Find-modules which are actually used by the
> > lib's buildsystem are located. A little bit confusing, at least for me the
> > template file would be ideally in a separate file and even have a special
> > name, like "Find*.cmake.template" or similar, to help discoverability.
> > 
> > Do you have a proposal or know a pattern-to-follow how to name and where
> > to
> > place such Find-module templates? Would be nice if there could be some
> > standard.
> > 
> > E.g. for my RIFF-parser lib libkoralle I would like to ship a template
> > Find- module, but also want any user of the lib discover what I provided
> > for them, so my work is not uselessly duplicated. Placing that in
> > extra-cmake-modules would help only KDE-centric devs, no?
> 
> No, extra-cmake-modules will have no KDE dependencies at all, it is
> explicitely meant for everybody (which also includes KDE).
> 
> There will be the first release this spring or early summer, at the latest
> at the same time of the first KDE frameworks alpha/beta/preview/whatever
> release.
> 
> So, if you want to distribute a Find-module, without getting it into cmake,
> but also without any additional dependencies, extra-cmake-modules will be
> the place to put it.

Hm... then I see an issue with extra-cmake-modules:
any lib released since the latest extra-cmake-modules will not be supported, 
if there is a BIC change in it. Will suck especially with also adding 
distribution releases into the game, which might pick up the latest lib 
version, but an older extra-cmake-modules which has not yet support for that 
lib version.

So any dev wanting to make use of that lib cannot rely on extra-cmake-modules 
and has to do things himself. Which somehow renders extra-cmake-modules a 
little bit useless for me (as usually as dev you want the latest-and-coolest 
version of some lib).

Or will extra-cmake-modules be some kind of online-repo of cmake modules with 
a rolling release, so if you need some Find-module you always grep what is 
there, hoping someone has already done support for any latest version? Where 
each module is independently updated, without a real version, like Wikipedia 
pages?

Friedrich