Le jeudi 28 novembre 2013 07:41:19 Ben Cooksley a écrit : > On Nov 28, 2013 7:26 AM, "Aurélien Gâteau" <agat...@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? Aurélien _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
