Initial support for kde_projects.xml in kdesrc-build

[Alexander Neundorf]

On Tuesday 01 February 2011, Michael Jansen 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.

Yes, with git this has become more stuff.

> kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems
> as early as possible?

I was asking specifically about "KDE" stuff, i.e. everything starting with 
kdelibs, not stuff kdelibs depends on (which I also mentioned in my previous 
mail that this is not too easy to get set up, as you can see above).

> > > 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? 

I don't get that far to actually run the stuff I've compiled...
A lot of the work I do _for_ KDE is actually work _on_ CMake nowadays.

> 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, 

I don't think so. I never set it for anything. Just use CMAKE_PREFIX_PATH. If 
something is not found without pkgconfig that's a bug.

> QTDIR (self compiled qt), 

Do you need that for running ?
For building it's not necessary. Use CMAKE_PREFIX_PATH.

> PATH so your self compiled stuff

For building it's not necessary. Use CMAKE_PREFIX_PATH.

> is picked up, LD_LIBRARY_PATH if you want to run stuff, 

RPATH is not working for you ?
This would be a bug.

> XDG_DATA_DIRS, KDEDIRS.

This is for running, not for building, right ?

> > > 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?
>
> The kdesupport order is much harder to get right.
>
> The strigi order?

kdesupport and strigi are before KDE, as mentioned above.
This doesn't make it easier, but it is not necessarily anymore in the scope of 
KDE.

> Quick. Order these smokegen, smokeqt, smokekde, qtruby, korundum.

Ok. kdebindings is weird.

> > > 4. which branches, version from which repo (only relevant for some
> > > modules)
> >
> > You mean now with git or also with "old" svn ?
>
> Have you ever tried to compile ktorrent? I mean with old svn too. But i
> expect that to get a tad more difficult with git unless we get a real
> common branching names strategy.

We really need that.

Alex