<div dir="ltr">On Thu, Nov 28, 2013 at 9:10 AM, Aurélien Gâteau <span dir="ltr"><<a href="mailto:agateau@kde.org" target="_blank">agateau@kde.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Le jeudi 28 novembre 2013 07:41:19 Ben Cooksley a écrit :<br>

<div class="im">> On Nov 28, 2013 7:26 AM, "Aurélien Gâteau" <<a href="mailto:agateau@kde.org">agateau@kde.org</a>> wrote:<br>
> > Le mercredi 27 novembre 2013 10:16:57 Ben Cooksley a écrit :<br>
> > > Hi,<br>
> > ><br>
> > > > I just disabled it, so that you can give it a try. Can you modify<br>
><br>
> kdelibs<br>
><br>
> > > > job<br>
> > > > definition so that cmake is called with -DSUPERBUILD=ON and "make<br>
><br>
> sb_all"<br>
><br>
> > > > is<br>
> > > > called first, then "make"?<br>
> > ><br>
> > > That has now been done in 6a67a97e79f1c0251bf0038e8ecd46dbe59cae72 to<br>
> > > sysadmin/build-kde-org.<br>
> > > Unfortunately the build failed.<br>
> ><br>
> > So I spent my day on that failure and <a href="http://build.kde.org" target="_blank">build.kde.org</a> is still red. The<br>
><br>
> failure<br>
><br>
> > is caused by meinproc5 not finding the kdex.dtd file. It should be fixed<br>
><br>
> by<br>
><br>
> > defining the XDG_DATA_DIRS variable to "$CMAKE_INSTALL_PREFIX/share/" or<br>
> > whatever dir where meinproc can find<br>
><br>
> "ksgmltools2/customization/dtd/kdex.dtd",<br>
><br>
> > installed by kdoctools (Ben, can you look into this?)<br>
><br>
> That is not possible I'm afraid - we have to keep the install prefix out of<br>
> cmake_prefix_paths and other env variables otherwise fresh builds would be<br>
> contaminated by prior runs.<br>
<br>
</div>Any framework which depends on kdoctools needs the binaries and files<br>
installed by kdoctools, so we need a way to do this. It used to be OK not do<br>
so this because kdoctools was used in "bootstrap" mode: it used files from<br>
kdelibs, but that is not applicable when building in standalone mode.<br>
<br>
The situation is similar to, say, kde-baseapps or kdepim needing kdoctools:<br>
how is Jenkins set up so that they can make use of kdoctools?<br></blockquote><div><br></div><div style>This is done through generate_environment() of tools/kdecilib.py.</div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Aurélien<br>
</font></span></blockquote></div><br></div><div class="gmail_extra" style>Thanks,</div><div class="gmail_extra" style>Ben</div></div>