KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)

[Alexander Neundorf]

On Wednesday 25 May 2011, Alexander Neundorf wrote:
> On Wednesday 25 May 2011, Eric Hameleers wrote:
> > On Tue, 24 May 2011, Alexander Neundorf wrote:
> > > On Sunday 22 May 2011, Alexander Neundorf wrote:
> > >> On Sunday 22 May 2011, Kevin Kofler wrote:
> > >>> On Sunday 22 May 2011, Alexander Neundorf wrote:
> > >>>> So, what I'm doing right now for kdesupport is to create one
> > >>>> CMakeLists.txt, which contains all the contained projects (automoc4,
> > >>>> phonon, attica, akonadi, ...) via the externalproject()-feature from
> > >>>> CMake.
> > >>>> What it does, is it gets and updates all the sources from git,
> > >>>> configures, builds and installs them.
> > >>>> So it feels almost like it did before.
> > >>> 
> > >>> Unfortunately, this is of no use for us packagers because we are
> > >>> banned by policy (and at least in Fedora, this is enforced by the
> > >>> build system) from downloading stuff during build. We can only work
> > >>> from tarballs. (If we want to package a snapshot, we have to check
> > >>> it out, tar it, then package the resulting tarball.)
> > >> 
> > >> I'll see whether I can do something for this.
> > >> 
> > >> Alex
> > > 
> > > Looks good :-)
> > > I have here now a CMakeLists.txt for kdesupport, which downloads
> > > everything from git and builds it.
> > > But on "make package", it creates basically a package of the downloaded
> > > sources together with a matching CMakeLists.txt (which then doesn't
> > > download, but just uses the already present sources).
> > > I.e.
> > > you could do "cmake <srcdir>" , then "make package" (or maybe some
> > > custom target), and then you'd have a tgz of kdesupport which you can
> > > unpack and build anywhere.
> > > Would that help your case ?
> > > 
> > > Alex
> > 
> > Hi Alex
> > 
> > Absolutely!
> > 
> > I have no issues with creating a comprehensive tarball myself. In
> > fact, if this allows me to build a single monolithic kdesupport
> > package again, then you provide what I need.
> 
> I think so.
> There may be issues with installing the built stuff, we'll see.
> (currently it is installed during the build, so you need write permissions
> for the install directory, which is probably ok for developers, who have
> their system probably anyway set up in such a way that they can install as
> normal user, not sure for packagers).
> 
> Where should I put that stuff ?
> git, svn, somewhere else ?

Attached is what I have so far for kdesupport.
There are still issues because some of the projects in kdesupport try to 
install outside CMAKE_INSTALL_PREFIX by default, those projects have to be 
fixed.

The file uses the ExternalProject-support from cmake to gather all the 
projects into one "superproject".
If you simply build it (cmake; make), it will download, configure and build 
them all.
During building it will also install them to their install location.

If you just want to have a source package which you can build, there is a 
custom target "UpdateAll" provided, which just gets all the sources.
To get a package from that, use the package target.
I.e.
$ make UpdateAll
$ make package

gives you a KDESupport-1.2.3.tgz, which you can unpack anywhere and configure 
there (for all of the included projects at once).


Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeLists.txt
Type: text/x-cmake
Size: 4178 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/release-team/attachments/20110526/ddd0aba7/attachment.bin