Review Request 113506: Add a sb_all target and sb_$framework targets to make it easier to build frameworks standalone

[Ben Cooksley]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131119/1eba74c7/attachment.html>