RFC: Release Management Going Forward
neundorf at kde.org
Wed Jul 27 20:22:08 CEST 2011
On Wednesday 27 July 2011, Dirk Mueller wrote:
> On Sunday 17 July 2011, Alexander Neundorf wrote:
> > It's still in the early phase, but it should work already.
> > With these superbuilds, you can create e.g. a standalone source package
> > for all of e.g. kdegraphics. When creating such a source package, you
> > can/have to enter the git tag e.g. via cmake-gui, then the source
> > package will be for this tag.
> > Or, you can build all of kdegraphics in one go directly from git.
The documentation here: https://projects.kde.org/projects/kde/superbuild
should be up-to-date and mostly complete.
> how does that work? I set SB_PACKAGE_VERSION_NUMBER to v4.7.0, but it
> still checked out git master, which is completely wrong.
> how do I tell it to check out a specific tag instead?
Set the SB_GIT_TAG variable in the cmake cache.
> also, why are the subdirectory names completely different (capitalized
> instead of lower case like the fine grained tarballs)?
No special reason. In the beginning I thought it looks nicer. But now I think
it would be probably a better idea to name them consistently like the git
We can change that.
> why is there a
> Source/ subdir where the main subdir does not have a CMakeLists.txt, so
> that the usual "cmake ; make; make install" workflow does not work?
The Source/ directory is just a container for the checked out projects. The
toplevel CMakeLists.txt is the one in the checkout out superbuild directory.
So you can do "cmake; make" there.
> is there a way to tell it to not run make install after every module?
And I think this is impossible.
Let's say there is a library libfoo and an application using it names KBar.
KBar will have a find_package(foo) in its CMakeLists.txt.
The find-module used by KBar at cmake time can only work if libfoo has already
been installed at this time.
So libfoo must already have been built and installed, so it can be found by
That's why installing is done during building.
And libfoo must be installed already with its final and correct
CMAKE_INSTALL_PREFIX, otherwise several things can go wrong, e.g. would KBar
get wrong RPATHs (if RPATHs are used), which would point to the intermediate
location, or maybe it would grep for something in a header installed by libfoo
to find some path, which could be dependent on the install location, and would
get a wrong result then if libfoo would not have been installed to the final
It is possible to use DESTDIR, so the package are not installed to the system
directory, but into DESTDIR.
If this is used, then RPATH must be completely disabled, because the
automatically calculated RPATH of KBar would point into the DESTDIR install
location of libfoo.
> for packagers, the step of "make" and "make install" must be completely
Sune (from Debian) said that the approach with Superbuild is different from
normal behaviour, but it could be handled for packaging (as long as DESTDIR
works). So, after "cmake ...; make" all the stuff is installed already in
Why do "make" and "make install" have to be completey separate in your case ?
> In this state I don't see that I can create monolithic tarballs from that
> method, I would prefer to run the old setup-kde*.sh scripts (from
> Anything I'm doing wrong here? I might have not grasped every part of the
> Any help appreciated.
Thanks for giving it a try :-)
I'd be happy if we can get it into a state where it works for you.
More information about the release-team