Superbuild in kdelibs

[Aurélien Gâteau]

Le jeudi 28 novembre 2013 08:21:13 Aurélien Gâteau a écrit :
> Le jeudi 28 novembre 2013 19:58:38 Ben Cooksley a écrit :
> > 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.
> 
> OK, I am going to look into modifying kdoctools "bootstrap" mode to work
> with superbuild.

After much wrestling with that, I cannot find any way to get superbuild to 
work on build.kde.org, because of the use of DESTDIR. Someone with enough 
karma should apply attached patch on build-kde-org repository to disable it 
and make Jenkins useful again.

It's not too bad anyway since this won't be a problem anymore when 
repositories are split. Meanwhile, I am going to continue running my daily 
script to build kdelibs with superbuild together with the rest of plasma2 in 
order to catch failures.

Aurélien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Revert-Build-kdelibs-frameworks-with-Superbuild.patch
Type: text/x-patch
Size: 979 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131128/26335ebc/attachment.patch>