kdesupport rearrangement

[Allen Winter]

On Sunday 28 September 2008 06:48:51 Tom Albers wrote:
> Hi, 
> 
> I think we have come to a conclusion, but not to a descision. Let's try to change that. Below you find the proposal based on the various mails to this list. I will wait untill there are a few supporters for this proposal, before posting it to k-c-d and k-d. Improvements are welcome too.
> 

I support this plan.
I also volunteer to help create the necessary CMakeLists.txt files.

> ------------------------------------------------------------------------------------------------------------------------
> 
> The release-team has decided to change the organisation of the kdesupport system we use. Please read the details below.
> 
> Problem
> ------------
> KDE development is devided in several branches, especially the current stable KDE branch and the unstable development branch in trunk. kdesupport libraries are independant of KDE, but KDE depends on them. At this moment there is no indication at all which kdesupport library should be used for a certain KDE branch.
> 
> We want a simple system for developers to just know for sure that you got the right kdesupport libraries when you want to compile a KDE tree completely from subversion.
> 
> Solution
> ------------
> For each main kde tree we will create a tag. For example for the current stable KDE release we create a tags/kdesupport-for-4.1/. Within that folder there are (cheap)copies of the kdesupport libraries which should be used for compiling the KDE 4.1 tree. For example:
>    tags/kdesupport-for-4.1/phonon/    (svn cp'ed from tags/phonon/4.2.0)
>    tags/kdesupport-for-4.1/strigi/    (svn cp'ed from tags/strigi/strigi/0.5.11)
>    tags/kdesupport-for-4.1/qca/    (svn cp'ed from tags/qca/2.0.1)
> Also, it will contain a CMake file, so all subdirectories can be build in one go. So if you want KDE4.1, just simply checkout this tag and you are done.
> 
> The same will go for trunk, so we will create a kdesupport-for-trunk. This also contains copies to the right version of the kdesupport libraries needed to build trunk. That means developers have a choise: either use trunk/kdesupport where development takes place, so that could lead to breakage in for example kdelibs but you can probably fix them, or you choose to compile KDE trunk with kdesupport from /tags/kdesupport-for-trunk and you are sure kdelibs trunk compiles from it.
> 
> Who
> ------------
> The kdesupport maintainers should make sure that the right version if available in each tag. If they release a new version they update the copy with a simple svnn rm + svn cp. If some kdesupport developers think everyone should just use their trunk, they could just regularly rm+cp the "tag" from their trunk. An svn external would have been more appropiate in that case, but that's unfortunatly not an option.
> 
> When
> ------------
> We would like to have this infrastructure in place at november 1st.
> 
> Tom Albers
> w/RT-hat