Initial support for kde_projects.xml in kdesrc-build

[Dawit A]

On Tue, Feb 1, 2011 at 2:58 PM, Michael Jansen <info at michael-jansen.biz> wrote:
> On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote:
>> On Tuesday 01 February 2011, Michael Jansen wrote:
>> > On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote:
>> > > On Monday 31 January 2011, Aaron J. Seigo wrote:
>> > > > On Sunday, January 30, 2011, Michael Pyne wrote:
>> > > > > Like I said, "xml-support" branch on kdesrc-build git. If
>> > > > > you want
>> > > > > to
>> > > > > give
>> > > >
>> > > > _very_ cool. will the good news today never end? ;)
>> > > >
>> > > > serious question: once this is stabilized, can we make this the
>> > > > default recommended way of building KDE from git on techbase?
>> > > >
>> > > > pros that i can think of:
>> > > >
>> > > > * it would mean that we could cannibalize the docs for
>> > > > kdesrc-build for those pages on techbase
>> > > > * it would be a lot simpler to document than the current 7
>> > > > headed hydra monster pages we have now :)
>> > >
>> > > The big thing is getting all the required dependencies built and
>> > > installed, or do you see other things which are complicated in
>> > > building
>> > > KDE modules ?
>> >
>> > yes i do.
>> >
>> > 1. It is a lot of work. if you work on base and want to run trunk there
>> > is a myriad of modules to build to get a useful setup.
>>
>> kdelibs, kdepimlibs, then kdebase.
>
> So want Aaaron and me to miss out on kwebkit and scripting, and policykit and
> rekonq and ... konsole? How do you suppose to use your system without konsole.
>
> kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as
> early as possible?
>
>>
>> > 2. environment variables (which and how to setup). Separate build
>> > environment from distro stuff that could interfere.
>>
>> CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g.
>> to /opt/mystuff/
>
> Do you only compile stuff? Or do you run it too? Does strigi work for you?
>
> STRIGI_PLUGIN_PATH ... but i haven't tested for a while if it needed nowadays.
> Strigi would not work without it.
>
> PKG_CONFIG_PATH, QTDIR (self compiled qt), PATH so your self compiled stuff is
> picked up, LD_LIBRARY_PATH if you want to run stuff, XDG_DATA_DIRS, KDEDIRS.
>
>> > 3. build order
>>
>> Isn't that the same as 1. ?
>
> No. kwebkitpart has to be build after kdelibs and before kdebase. Did you know
> that? Do you expect Joe NewKdeUser to know?

ahhhh. nope. kwebkitpart only depends on kdelibs! There are no
requirements besides that. The previous requirement that you must
build kwebkitpart before you compiled the konq-plugins, which have now
been moved to kdebase, is now longer valid because of the addition of
several Extentsion interfaces to the KParts API. As a result
konq-plugins do not have direct dependency on kwebkitpart anymore in
KDE >= 4.6...