On Saturday 27 March 2010, Maciej Mrozowski wrote: > 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
Such a package will/should have the same compatibility requirements as the modules in kdelibs. This is actually my main point. Someone writes a module, it kind of works, and he tries to get it into <some always installed package>, so others can use it too. Good so far, but this also means this module has to keep compatibility starting with the first release, for the years to come. Such a separate package would be like a libkrandomstuff.so, which is required by kdelibs but doesn't provide any compatibility guarantees. I think I'm not in favour of this idea. > 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. That's my main point. > It indeed is better in terms of compatibility, on the other hand it leads > to possibly unlimited number of possibly incompatible forks. Well, "forks". Let's say modified copies. Those modified copies don't have to be installed or published, so I wouldn't call it a fork (sounds like ongoing competetive development). And they can always update manually (<- important) again from that one central (but uninstalled) location. > Not bad idea imho. Others ? Alex _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest