RFC v2: adding a temporary, non-BC gauranteed, 'private' library

[Alexander Neundorf]

On Wednesday 06 May 2009, Aaron J. Seigo wrote:
> On Tuesday 05 May 2009, Sune Vuorela wrote:
> > No. This is not a matter of packaging it. This is a matter of attracting
> > new small contributions, a matter of making it accessible, ....
>
> the alternative of hundreds of small modules is that it becomes utterly
> painful to build and maintain an entire desktop build. having our big
> modules doesn't actually make it any harder to work on just one app; i do
> it all the time and there are instructions on how to do this at the end of
> this email.
>
> > I know how to do packaging - and I still don't get paid even though you
> > seems to claim it from time to time.
>
> i'm not interested in trading snipes with you. keep the conversation on a
> mature level so we can be productive.
>
> > I often get asked by people who wants to fix their pet bug in kmail or
> > kopete or klipper or .... but end up not wanting to do it because they
> > can't easily just build klipper without building entire
> > kdebase/workspace.
>
> svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/workspace
> mkdir -p build/workspace
> cd build/workspace
> cmake ../../workspace
> cd klipper
> make -j4 && make install
>
> voila. that's pretty easy, no?
>
> if you want to avoid checking out all the sources, then:
>
> svn co -N svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/workspace
> cd workspace
> svn up klipper
> vim CMakeLists.txt // remove all add_subdirectory calls except klippers

That last line is the ugly one.
E.g. kdepim/kjots/ can be built completely separately, i.e. you should be able 
to do 
svn co kdepim/kjots/
and then build it.

In general this is possible for all apps which don't depend on library in the 
same project, if the developer adds this functionality, there is no special 
support from FindKDE4Internal.cmake or something required.

Alex