[Kde-scm-interest] [Proposal] Package splitting with thin meta-repos

[Maciej Mrozowski]

On Friday 26 of March 2010 19:24:18 Alexander Neundorf wrote:
> On Friday 19 March 2010, Alexander Neundorf wrote:
> > On Thursday 11 February 2010, Alexander Neundorf wrote:
> > > On Monday 08 February 2010, Maciej Mrozowski wrote:
> > > > On Monday 08 of February 2010 12:42:02 Mike Arthur wrote:
> > > > > On 6 Feb 2010, at 14:41, Maciej Mrozowski wrote:
> > > > > > How about moving all shared .cmake files to either separate
> > > > > > package (or maybe with modules fetched from Internet, sth like
> > > > > > knewstuff or PEAR or just SVN) - as current kdelibs cmake
> > > > > > policies are too strict, besides rebuilding kdelibs just to get
> > > > > > newer cmake files seems silly. That would benefit both cases
> > > > > > imho.

Refining this initial idea:
What about setting up sourceforce (or kdesupport/gitorious) project: cmake-
modules, being modules incubator for cmake
- with own release schedules
- depending on >= particular cmake version
- installing .cmake modules in unknown <some_modules_path>
- providing own FindCMakeModules.cmake file that sets 
CMAKE_MODULE_PATH=<some_modules_path> and provides CMAKEMODULES_VERSION (so 
that find_package(CMakeModules <version>) can be used

Main (only?) benefit is being decoupled from kdelibs (so more relaxed 
schedules), also - ideally it would allow to get rid of all application-local 
modules. It brings additional maintenance cost (releases etc) but would be 
neutral (not tied to KDE) and thus maybe KitWare itself could be more 
interested in such idea.
CMake is getting more and more popular, but it's sad seeing so many poorly 
written CMake buildsystems worldwide with locally hacked, sub-optimal .cmake 
modules only because there's no community-driven central place for their 
development and because those provided by cmake itself are not ideal either.

> > > > > How are the current KDELibs CMake policies "too strict"? What
> > > > > problems are these causing?
> > > > 
> > > > http://techbase.kde.org/Policies/CMake_and_Source_Compatibility
> > > > (general) http://techbase.kde.org/Policies/CMake_Commit_Policy
> > > > (kdelibs/cmake)
> > > > 
> > > > KDElibs CMake policies cause no problems - they solve them. It's just
> > > > this strictness currently may seem to discourage developers from
> > > > getting their .cmake files in shape and pushing them to kdelibs
> > > > instead of bundling within modules (like kdenetwork etc).
> > > 
> > > If we would have another package just consisting of cmake files, I
> > > think the same rules would have to apply to it, and I think this may
> > > have the same effect on the developers.
> > > Installing cmake files comes with a cost, so not sharing them if they
> > > are used only in some very rare cases also has advantages.
> > 
> > How about this: instead of installing a bunch of FindFoo.cmake files, we
> > could just collect them e.g. in kdesdk/cmake/modules/ or something like
> > that. If somebody needs a module, he gets a copy from there and includes
> > this in his application.
> > This way we wouldn't have to care about compatibility, and still we would
> > have a place where people could manually get cmake find-module files.

Hmm, my first thought was that it's going to be worse than current situation 
as one cannot automatically propagate fixes to those .cmake files in such 
case.
But in the same way, one cannot automatically break those modules so there is 
some merit in this.
It indeed is better in terms of compatibility, on the other hand it leads to 
possibly unlimited number of possibly incompatible forks.
Not bad idea imho.

-- 
regards
MM