Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-22 Thread Alexander Neundorf
On Monday 22 August 2011, Jeremy Whiting wrote:
> On Sun, Aug 21, 2011 at 5:06 PM, Lukas Appelhans  wrote:
> > On Sunday 21 August 2011 23:13:30 George Goldberg wrote:
> > > On 21 August 2011 14:05, Lukas Appelhans  wrote:
> > > > Hey!
> > > > 
> > > > Cool... I see you go for a split up of kdenetwork (makes sense imo).
> > > 
> > > Yup. Definitely.
> > > 
> > > > The problem I see at the moment you have to build all applications
> > > > together in kdenetwork, otherwise they fail to compile. So this is a
> > > > first thing which needs to change.
> > > 
> > > Others have already answered this - some of the apps already build
> > > standalone, others will need a bit of cmake modifications first.
> > 
> > Yes. I will see what I can do about that in the next weeks. :)
> > 
> > > > What is missing are tags and branches right?
> > > 
> > > Yes. I think I've got the whole trunk history sorted iirc. Haven't
> > > done the tags and branches though.
> > 
> > Okay.
> 
> It's not needed to make all the tags and branches build standalone and
> together.  

Yes.
And it is also relatively hard to get this right.
I have a slightly bad feeling when I read here posts that some modules have 
been tweaked so they can be built both ways, because to do this, you have to 
be aware of quite some details in cmake behaviour, like how cache variables 
behave, how targets, libraries and library search paths are handled, etc.

Currently I don't have the time to go through all (...and we have _many_ now) 
git repositories and check whether they are doing it the right way.

I recommend that the git repos build standalone, and do find_package() for 
their dependencies.

All installed libraries should export their targets and install a cmake 
Config.cmake file.

To build the modules as they were, a tool like kdesrc-build, buildtool or KDE 
superbuild (https://projects.kde.org/projects/kde/superbuild) should be used.

Alex


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-22 Thread Jeremy Whiting
On Sun, Aug 21, 2011 at 5:06 PM, Lukas Appelhans  wrote:

> On Sunday 21 August 2011 23:13:30 George Goldberg wrote:
> > On 21 August 2011 14:05, Lukas Appelhans  wrote:
> > > Hey!
> > >
> > > Cool... I see you go for a split up of kdenetwork (makes sense imo).
> >
> > Yup. Definitely.
> >
> > > The problem I see at the moment you have to build all applications
> > > together in kdenetwork, otherwise they fail to compile. So this is a
> > > first thing which needs to change.
> >
> > Others have already answered this - some of the apps already build
> > standalone, others will need a bit of cmake modifications first.
> Yes. I will see what I can do about that in the next weeks. :)
> >
> > > What is missing are tags and branches right?
> >
> > Yes. I think I've got the whole trunk history sorted iirc. Haven't
> > done the tags and branches though.
> Okay.
>

It's not needed to make all the tags and branches build standalone and
together.  If someone wants to re-create  an old tag or branch they will
most likely need to build the whole module together anyway.  Doing the
changes for master/trunk and 4.7 branch is enough.  Usually doing the
changes on trunk is enough then the CMakeLists.txt changes can be easily
cherry-picked to the 4.7 branch after the migration to git.

Jeremy

>
> Lukas
> >
> > --
> > George


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread Lukas Appelhans
On Sunday 21 August 2011 23:13:30 George Goldberg wrote:
> On 21 August 2011 14:05, Lukas Appelhans  wrote:
> > Hey!
> > 
> > Cool... I see you go for a split up of kdenetwork (makes sense imo).
> 
> Yup. Definitely.
> 
> > The problem I see at the moment you have to build all applications
> > together in kdenetwork, otherwise they fail to compile. So this is a
> > first thing which needs to change.
> 
> Others have already answered this - some of the apps already build
> standalone, others will need a bit of cmake modifications first.
Yes. I will see what I can do about that in the next weeks. :)
> 
> > What is missing are tags and branches right?
> 
> Yes. I think I've got the whole trunk history sorted iirc. Haven't
> done the tags and branches though.
Okay.

Lukas
> 
> --
> George

signature.asc
Description: This is a digitally signed message part.


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread George Goldberg
On 21 August 2011 14:05, Lukas Appelhans  wrote:
> Hey!
>
> Cool... I see you go for a split up of kdenetwork (makes sense imo).

Yup. Definitely.

> The problem I see at the moment you have to build all applications together in
> kdenetwork, otherwise they fail to compile. So this is a first thing which
> needs to change.

Others have already answered this - some of the apps already build
standalone, others will need a bit of cmake modifications first.

> What is missing are tags and branches right?

Yes. I think I've got the whole trunk history sorted iirc. Haven't
done the tags and branches though.

--
George


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread Rolf Eike Beer
Am Sonntag, 21. August 2011, 18:41:35 schrieb Lukas Appelhans:
> On Sunday 21 August 2011 17:27:01 George Kiagiadakis wrote:
> > On Sun, Aug 21, 2011 at 4:05 PM, Lukas Appelhans  
wrote:
> > > Hey!
> > > 
> > > Cool... I see you go for a split up of kdenetwork (makes sense imo).
> > > 
> > > The problem I see at the moment you have to build all applications
> > > together in kdenetwork, otherwise they fail to compile. So this is a
> > > first thing which needs to change.
> > 
> > It is not really required to build them all together. I used to have
> > git-svn clones of krdc, krfb and kopete and built them separately.
> > Actually, all the work I have done on krfb was done this way. Iirc
> > there is extra cmake code in there to ensure that they build both
> > standalone and all together.
> 
> Okay. This is not true for KGet though: All searching for dependencies is
> done in the top-level CMakeLists.txt.

Which had been the case in kdeutils also. Until the git migration started e.g. 
the top level CMakeLists.txt in kdeutils checked if gmp is present and only 
then included kcalc. This is no showstopper, it just means that someone needs 
to change it.

Eike

signature.asc
Description: This is a digitally signed message part.


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread Lukas Appelhans
On Sunday 21 August 2011 17:27:01 George Kiagiadakis wrote:
> On Sun, Aug 21, 2011 at 4:05 PM, Lukas Appelhans  wrote:
> > Hey!
> > 
> > Cool... I see you go for a split up of kdenetwork (makes sense imo).
> > 
> > The problem I see at the moment you have to build all applications
> > together in kdenetwork, otherwise they fail to compile. So this is a
> > first thing which needs to change.
> 
> It is not really required to build them all together. I used to have
> git-svn clones of krdc, krfb and kopete and built them separately.
> Actually, all the work I have done on krfb was done this way. Iirc
> there is extra cmake code in there to ensure that they build both
> standalone and all together.
Okay. This is not true for KGet though: All searching for dependencies is done 
in the top-level CMakeLists.txt.

Lukas
> 
> > What is missing are tags and branches right?
> > 
> > Lukas
> > 
> > PS: The KGet "svn cp" comment is (I guess) about this branch:
> > http://websvn.kde.org/branches/work/make_kget_cool/?pathrev=647221
> > As far as I know this is the KGet2 rewrite and was copied to trunk
> > then...> 
> >> I have partially written the rules for kdenetwork, but they are not
> >> complete. I don't have time to work on them at the moment, so someone
> >> else taking that over would be good if it's going to happen any time
> >> soon. The work I've done so far is in the git repository with all the
> >> other conversion rules.
> >> 
> >> --
> >> George

signature.asc
Description: This is a digitally signed message part.


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread George Kiagiadakis
On Sun, Aug 21, 2011 at 4:05 PM, Lukas Appelhans  wrote:
> Hey!
>
> Cool... I see you go for a split up of kdenetwork (makes sense imo).
>
> The problem I see at the moment you have to build all applications together in
> kdenetwork, otherwise they fail to compile. So this is a first thing which
> needs to change.

It is not really required to build them all together. I used to have
git-svn clones of krdc, krfb and kopete and built them separately.
Actually, all the work I have done on krfb was done this way. Iirc
there is extra cmake code in there to ensure that they build both
standalone and all together.

> What is missing are tags and branches right?
>
> Lukas
>
> PS: The KGet "svn cp" comment is (I guess) about this branch:
> http://websvn.kde.org/branches/work/make_kget_cool/?pathrev=647221
> As far as I know this is the KGet2 rewrite and was copied to trunk then...
>
>> I have partially written the rules for kdenetwork, but they are not
>> complete. I don't have time to work on them at the moment, so someone
>> else taking that over would be good if it's going to happen any time
>> soon. The work I've done so far is in the git repository with all the
>> other conversion rules.
>>
>> --
>> George


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread Stefan Majewsky
On Fri, Aug 19, 2011 at 9:27 PM, John Layt  wrote:
> The kde-wallpapers and kdeartwork modules are likely to remain in svn until
> git handles binary blobs better.  Then there is also a lot of stuff still in
> extragear and playground.

This is an issue with kdegames as well: A complete source tree is 112
megabytes, of which about AFAIR 80% is data (SVGZ, audio files,
levelsets, etc.). Some months ago, I've proposed on kde-games-devel@
to split a kdegames-data module from kdegames. The discussion ended
because we decided not to switch to git before a workflow exists to
handle split repositories. (With SuperBuild being available now, this
discussion probably needs to be restarted.)

What I proposed:
1. Freeze trunk/KDE/kdegames, conserve this state as kdegames-history.git
2. Move all data files from trunk/KDE/kdegames to trunk/KDE/kdegames-data.
3. Move the source code to git.kde.org (as fresh repos, to avoid data
blobs in the object db).
4. Optionally patch the games to run without data. This is because the
build order of the modules would be: kdegames, then kdegames-data.

Greetings
Stefan


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread Lukas Appelhans
Hey!

Cool... I see you go for a split up of kdenetwork (makes sense imo).

The problem I see at the moment you have to build all applications together in 
kdenetwork, otherwise they fail to compile. So this is a first thing which 
needs to change.

What is missing are tags and branches right?

Lukas

PS: The KGet "svn cp" comment is (I guess) about this branch: 
http://websvn.kde.org/branches/work/make_kget_cool/?pathrev=647221
As far as I know this is the KGet2 rewrite and was copied to trunk then...

> I have partially written the rules for kdenetwork, but they are not
> complete. I don't have time to work on them at the moment, so someone
> else taking that over would be good if it's going to happen any time
> soon. The work I've done so far is in the git repository with all the
> other conversion rules.
> 
> --
> George

signature.asc
Description: This is a digitally signed message part.


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-21 Thread George Goldberg
On 19 August 2011 22:18, Jeremy Whiting  wrote:
> On Fri, Aug 19, 2011 at 1:27 PM, John Layt  wrote:
>>
>> On Friday 19 Aug 2011 19:54:21 Harald Sitter wrote:
>> > On Fri, Aug 19, 2011 at 6:54 PM, Lukas Appelhans 
>> > wrote:
>> > > I guess there were no efforts yet from the kdemultimedia team to make
>> > > the
>> > > move.
>> >
>> > I did not realize we had to take care of the move seems a bit
>> > inconvenient.
>>
>> Yep, you need to mak e it happen as it involves decision no-one else can
>> make
>> for you.  There's basically three steps needed.  First, you have to decide
>> on
>> separate Git repos per app or stick with the monolithic module.  Second,
>> if
>> going for separete repos make sure everything actually builds properly
>> that
>> way.  Third you need to write the conversion rules for you history, but
>> there's a few people around who may be willing to help out with that once
>> you
>> know what you want.  Have a chat on the #kde-git channel for more details.
>>
>> On the subject of un-converted svn modules, the following are still left:
>>
>>  kdeaccessibility
>>  kdeadmin
>>  kdegames
>>  kdemultimedia
>>  kdenetwork

I have partially written the rules for kdenetwork, but they are not
complete. I don't have time to work on them at the moment, so someone
else taking that over would be good if it's going to happen any time
soon. The work I've done so far is in the git repository with all the
other conversion rules.

--
George


Re: Git migration status (Was: Re: Where is kmix hidden?)

2011-08-19 Thread Jeremy Whiting
On Fri, Aug 19, 2011 at 1:27 PM, John Layt  wrote:

> On Friday 19 Aug 2011 19:54:21 Harald Sitter wrote:
> > On Fri, Aug 19, 2011 at 6:54 PM, Lukas Appelhans 
> wrote:
> > > I guess there were no efforts yet from the kdemultimedia team to make
> the
> > > move.
> >
> > I did not realize we had to take care of the move seems a bit
> > inconvenient.
>
> Yep, you need to mak e it happen as it involves decision no-one else can
> make
> for you.  There's basically three steps needed.  First, you have to decide
> on
> separate Git repos per app or stick with the monolithic module.  Second, if
> going for separete repos make sure everything actually builds properly that
> way.  Third you need to write the conversion rules for you history, but
> there's a few people around who may be willing to help out with that once
> you
> know what you want.  Have a chat on the #kde-git channel for more details.
>
> On the subject of un-converted svn modules, the following are still left:
>
>  kdeaccessibility
>  kdeadmin
>  kdegames
>  kdemultimedia
>  kdenetwork
>  kdesdk
>  kdetoys
>  kdeutils
>  kdewebdev
>

kdeaccessibility should be done this weekend.  Same with kdeutils.

According to the MoveToGit page on techbase kdegames rules are 99% done, but
not sure if that's with split repos or not.

Jeremy


>
> The kde-wallpapers and kdeartwork modules are likely to remain in svn until
> git handles binary blobs better.  Then there is also a lot of stuff still
> in
> extragear and playground.
>
> Does anyone know the status of these modules?  Do we need to start poking
> the
> maintainers?  Now is a good time to do conversions as it's a few months
> before
> our next beta release and we'd want any moves settled in by then.
>
> Cheers!
>
> John.
>


Git migration status (Was: Re: Where is kmix hidden?)

2011-08-19 Thread John Layt
On Friday 19 Aug 2011 19:54:21 Harald Sitter wrote:
> On Fri, Aug 19, 2011 at 6:54 PM, Lukas Appelhans  wrote:
> > I guess there were no efforts yet from the kdemultimedia team to make the
> > move.
> 
> I did not realize we had to take care of the move seems a bit
> inconvenient.

Yep, you need to mak e it happen as it involves decision no-one else can make 
for you.  There's basically three steps needed.  First, you have to decide on 
separate Git repos per app or stick with the monolithic module.  Second, if 
going for separete repos make sure everything actually builds properly that 
way.  Third you need to write the conversion rules for you history, but 
there's a few people around who may be willing to help out with that once you 
know what you want.  Have a chat on the #kde-git channel for more details.

On the subject of un-converted svn modules, the following are still left:

  kdeaccessibility
  kdeadmin
  kdegames
  kdemultimedia
  kdenetwork
  kdesdk
  kdetoys
  kdeutils
  kdewebdev

The kde-wallpapers and kdeartwork modules are likely to remain in svn until 
git handles binary blobs better.  Then there is also a lot of stuff still in 
extragear and playground.

Does anyone know the status of these modules?  Do we need to start poking the 
maintainers?  Now is a good time to do conversions as it's a few months before 
our next beta release and we'd want any moves settled in by then.

Cheers!

John.