Superbuild in kdelibs

[Ben Cooksley]

On Thu, Nov 28, 2013 at 9:10 AM, Aurélien Gâteau <agateau at kde.org> wrote:

> Le jeudi 28 novembre 2013 07:41:19 Ben Cooksley a écrit :
> > On Nov 28, 2013 7:26 AM, "Aurélien Gâteau" <agateau at kde.org> wrote:
> > > Le mercredi 27 novembre 2013 10:16:57 Ben Cooksley a écrit :
> > > > Hi,
> > > >
> > > > > I just disabled it, so that you can give it a try. Can you modify
> >
> > kdelibs
> >
> > > > > job
> > > > > definition so that cmake is called with -DSUPERBUILD=ON and "make
> >
> > sb_all"
> >
> > > > > is
> > > > > called first, then "make"?
> > > >
> > > > That has now been done in 6a67a97e79f1c0251bf0038e8ecd46dbe59cae72 to
> > > > sysadmin/build-kde-org.
> > > > Unfortunately the build failed.
> > >
> > > So I spent my day on that failure and build.kde.org is still red. The
> >
> > failure
> >
> > > is caused by meinproc5 not finding the kdex.dtd file. It should be
> fixed
> >
> > by
> >
> > > defining the XDG_DATA_DIRS variable to "$CMAKE_INSTALL_PREFIX/share/"
> or
> > > whatever dir where meinproc can find
> >
> > "ksgmltools2/customization/dtd/kdex.dtd",
> >
> > > installed by kdoctools (Ben, can you look into this?)
> >
> > That is not possible I'm afraid - we have to keep the install prefix out
> of
> > cmake_prefix_paths and other env variables otherwise fresh builds would
> be
> > contaminated by prior runs.
>
> Any framework which depends on kdoctools needs the binaries and files
> installed by kdoctools, so we need a way to do this. It used to be OK not
> do
> so this because kdoctools was used in "bootstrap" mode: it used files from
> kdelibs, but that is not applicable when building in standalone mode.
>
> The situation is similar to, say, kde-baseapps or kdepim needing kdoctools:
> how is Jenkins set up so that they can make use of kdoctools?
>

This is done through generate_environment() of tools/kdecilib.py.
Every project has a set of dependencies, which the scripts will examine and
set environment variables for appropriately to ensure they are available.
This covers path, cmake_prefix_path, xdg_data_dirs, etc.

The problem in this case is because kdelibs cannot depend on itself -
Superbuild needs to handle that. Once the frameworks have split they will
be able to declare their dependencies against each other through the usual
mechanism (so it will "just work"). This is how it works for everything
else at the moment.


> Aurélien
>

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131128/2c155296/attachment-0001.html>