> On Nov. 12, 2013, 5:11 p.m., Aleix Pol Gonzalez wrote: > > CMakeLists.txt, line 18 > > <http://git.reviewboard.kde.org/r/113506/diff/5/?file=211419#file211419line18> > > > > I don't think we want that, superbuild shouldn't be used after the > > splitting but the kde build script. We will need it anyway and it will have > > all the needed information anyway. > > Aurélien Gâteau wrote: > I did this to make it as simple as possible to use superbuild: no need to > run cmake again, just use the already available targets. When superbuild is > removed it can go away with it so I don't think it is a problem. > > Aleix Pol Gonzalez wrote: > I have 2 kdelibs build directories: one with monolithic and one with > superbuild, I don't feel like this is a problem to me. > > Aurélien Gâteau wrote: > Sure it is not, but you made a conscious effort to set it up. > > Furthermore, not requiring a separate build dir makes like easier for > build.kde.org maintainers: they just need to add another target to the "make" > call. > > Aleix Pol Gonzalez wrote: > Well, I'd say that we probably want to have a separate install for both > in bko. > > I have no idea of how hard this is to set up in jenkins, if the goal is > to make it possible for build.kde.org to test it, I won't oppose. > > Aurélien Gâteau wrote: > Having separate install dirs on build.k.o would be ideal, but IIRC it was > not easy to get done. I could be wrong though. > > Anyway, regardless of build.k.o, I think it is worth making it as easy as > possible to start a standalone build. Having separate build and install > directories is a good practice and should be encouraged but requires more > work so people are less likely to set this up, which means they won't > proactively check they did not break anything. That is why I want it to be > done this way.
Unfortunately the way build.kde.org has been constructed means having a separate build is a little difficult. The only way I can see would be to change kdelibs_frameworks_qt5 to be a Multi-Configuration Job, and then use separate variations to build the normal and superbuild variants. However, the deployment of one of these would ultimately have to be suppressed - as both would be targeting the same final install location. We would be able to simulate "make install" without issue however. - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/#review43533 ----------------------------------------------------------- On Nov. 13, 2013, 1:07 p.m., Aurélien Gâteau wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113506/ > ----------------------------------------------------------- > > (Updated Nov. 13, 2013, 1:07 p.m.) > > > Review request for Build System, KDE Frameworks, Alexander Neundorf, and > Stephen Kelly. > > > Repository: kdelibs > > > Description > ------- > > This patch rework superbuild to integrate it more closely with kdelibs build > system: one no longer needs to run cmake path/to/kdelibs/superbuild > separately. Instead targets are created for all frameworks declared in > superbuild/CMakeLists.txt. For example to build and install ki18n standalone, > one can run `make sb_ki18n`. It also adds a special "sb_all" target, which > builds and install all standalone frameworks. > > > Diffs > ----- > > CMakeLists.txt 879fed4 > superbuild/CMakeLists.txt cbe9630 > superbuild/README 7a4e52e > superbuild/SuperBuild.cmake 33ed151 > > Diff: http://git.reviewboard.kde.org/r/113506/diff/ > > > Testing > ------- > > kdelibs still builds standalone, all sb_* targets work as expected. > > > Thanks, > > Aurélien Gâteau > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
