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

[Maciej Mrozowski]

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.
> 
> 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).

Besides, as I noted, waiting for newer kdelibs only to get newer cmake modules 
(if it was the only allowed place for them - as it's supposed to reduce 
redundancy within build system) would be considerable work flow bottleneck, 
that being said I think it would be reasonable to have CMake files as separate 
package with own release schedules (or preferably just script directly 
downloading the most recent or tagged versions from SCM repo).

Of course it doesn't lift the need to apply mentioned QA policies to them, but 
should allow to simplify CMakeLists.txt files a bit...

Anyway, that was just random suggestion, by no means a blocker.

-- 
regards
MM