[Kde-scm-interest] KDESDK to git migration: Build system changes

[Sebastian Dörner]

On 2 June 2012 07:36, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> Am Freitag, 1. Juni 2012, 15:39:37 schrieb Jeremy Whiting:
>> On Fri, Jun 1, 2012 at 3:36 PM, Josef Weidendorfer
>>
>> <Josef.Weidendorfer at gmx.de> wrote:
>> > Am 01.06.2012 17:19, schrieb Friedrich W. H. Kossebau:
>> >> I just wrote in the parallel email that I would vote for following
>> >> Jeremy's
>> >>
>> >> proposal:
>> >>>>> The
>> >>>>> moving from top level to under the application can be done with
>> >>>>> svn2git rules though (and needs to be done for older branches/tags
>> >>>>> anyway), so I suggest we leave them in place in svn and move them as
>> >>>>> part of the migration to git.  I'll try to spend a bit of time this
>> >>>>> weekend remembering how that is done and doing the same for the
>> >>>>> kdesdk/doc folder in the rules.
>> >
>> > Yes, this is the right thing.
>> >
>> > However, no action needed: it is already taken care of in the common
>> > kdesdk rules, and seems to work well.
>> >
>> > Josef
>>
>> Ah, excellent.  I was looking forward to running the rules tomorrow.
>> Maybe I'll do that anyway, just for kicks.
>
> If you do so, can you see what can be done for doc/kmtrace?
> Because kmtrace was going to be moved to utils/kmtrace, and thus doc/kmtrace
> should ideally go to utils/doc/kmtrace. Well, would also need a new utils/doc
> and utils/doc/CMakeLists.txt, so better simply goes to utils/doc, can be
> changed after the migration for master then to be in another subdir
> utils/doc/kmtrace.
>
> Before I was going to commit the new utils/ right this morning, that
> doc/kmtrace always slipped my eyes  :/
>
> Hm, this utils/ thingie really complicates things. If I move the stuff in
> trunk now, than the rules which need to move the stuff automatically for the
> branches get more complicated, or? Asked about that on kde-scm-interest.
This is correct. Basically you have two options:
a) make rules a bit more complicated
b) have a broken build for the newly created repo (due to missing
top-level CMakeLists.txt)

I think it doesn't make much of a difference, but tend to prefer option b).
>
> Cheers
> Friedrich
> _______________________________________________
> kde-sdk-devel mailing list
> kde-sdk-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-sdk-devel