RFC: Release Management Going Forward

[Alexander Neundorf]

Hi Dirk,

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 
repository.
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? 

No.
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 
KBar.

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

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

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

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
> /trunk/KDE/kde-common/release).
> 
> Anything I'm doing wrong here? I might have not grasped every part of the
> README.
> 
> 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.

Alex