Snapshot of KDE 4.10 build environment (MinGW, 32bit)

[Patrick Spendrin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 06.05.2013 12:54, schrieb Thomas Friedrichsmeier:
> Hi,
> 
> On Sunday 05 May 2013 22:59:14 Patrick Spendrin wrote:
>> Hm, the problem of these kind of setups is, as you noted, that
>> you are restricted to a certain specific setup and you add the
>> builds themselves. I propose a different solution for the
>> future:
> 
> well, as you will have guessed, my archive is mostly a by-product
> of setting up the build environment for myself. À la: "Wow, I
> finally got it to work. Now let me make a backup, before I break
> it, again."
> 
> I'm all for a clean and "official" solution. Basing that on a
> snapshot of sources, only, sounds reasonable(*).
> 
>> 1) we somehow store the source files & make them downloadable as
>> a complete package (e.g. winkde-tools-4.10.2.7z + 
>> winkde-win32libs-4.10.2.7z + ...) which you simply can unpack
>> into your download directory. 2) using those packages, one can
>> make up ones own distribution by simply making a csv file (like
>> the ones in emerge\server\serverconfig): rkward-4.10.2.txt which
>> contains only references to tarball targets. The (re-)build
>> process would look like that: - - setup emerge (setting
>> EMERGE_OFFLINE=True) - - get the source & tool tarballs that were
>> saved for that release. - - run 'emerge
>> --list-file=rkward-4.10.2.txt' - - have the base for developing
>> on top of KDE on Windows.
> 
> Well, I am not sure I understand all implications. In this setup,
> would it be (easily) possible to go from such a "base" installation
> to a fully-functional emerge installation? I.e. will the sources
> end up in the same (relative) path as in a regular emerge setup?

Yes, they should be put simply into the download directory and are
taken from that. the only difference is that they are not fetched (by
switching to offline mode) and that special targets can be used (by
using the --list-file option).
To make this even more clear: the only things that don't exist yet,
are the source+tools tarballs, the emerge side is fully functional
already for that solution.

> 
>> alternative solution: we make it possible that emerge can
>> directly rebuild from the source packages made for the installer;
>> this is not that easy since all patches are already applied, and
>> some other packages simply move stuff around etc. and we only get
>> the resulting packages.
> 
> Just a thought: AFAICS, at this point of time, the main purpose of
> the source packages is to comply with distribution licence terms.
> Their practical value is rather limited (although with some
> determination, and willingness to apply dirty tricks, it is
> possible to use them as a basis for developing). So, would it make
> sense to re-think the source-packages, entirely?

Yes, that comes to my head from time to time.

> 
> Suppose a source package would be modelled somewhat more along the
> lines of debian / rpm / etc. source packages. I.e. each package
> would contain: - a) the pristine sources in the exact same for as
> used by emerge - b) the portage file and patches - c) (optional)
> meta-data The source package would be entirely self-contained. It
> would simply be "plugged" into an existing emerge installation, and
> continue to work like any other port from that point onwards.

Hm, a thing like that would probably need a new source type for emerge
which could extract the instructions from the package, resetup the
package and then the typical build instructions would happen. This
should be easy to get this working for packages that do not do
anything unusual, but at least for packages like Qt, this might be a
problem (whenever a package overloads fetch or unpack methods).
> 
> (And to dream on a bit, emerge would later gain the ability to also
> install released binaries, mixing those with self-compiled packages
> all magically.)

That actually had been possible for quite a while, the problem is less
about mixing those two binaries and more that our released packages
are not suitable for building in a new environment because they have
hardcoded paths in them. If you're curious about the occurances of
these, search for paths: F:==msvc,G:==mingw32,H:==mingw64.
The other point is regenerating the installation database of emerge
(emerge and the kdewin-installer use different systems), but this can
be handled too.

> 
> Well, point a) of the above sketch might be a bit of a problem for
> git- repositories due to size (modern compression tools like 7z
> should take care of that quite nicely, though), and read-write
> checkouts / clones. And of course I don't pretend to have the least
> idea on how difficult this scheme would be to implement, or what
> else it would break.

Well, my current goal is to have KDE releases on top of tarballed
source packages, so that my builds are 100% reproduceable.

> 
> Regards Thomas
> 
> (*): I do think two or three pre-compiled variants (matching the
> settings used for creating the release binaries) would still be
> nice to have in the long run. But in fact, for starters, the most
> important point is conserving a stable snapshot that "just works",
> and continues to work, indefinitely.

hm, hm, hm.

regards,
Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRiDi9AAoJELpJVkl28PNQb8gH/irU+qB3u+QemGaKIJHbF3yd
eDQHIvu2i3cjO3r0aMgl57MtoTmOBd7r2EMioFyiTOf3vHfQPxXSSrPizYyqMkJS
y5c9eHd2fFV2g/5uqNL4ssjXGTnnL7KZMAXw2pRQPZVIkzf7B2kvgKoYiaw2nkmf
UfcthFzxQ2Xz/krGIY4YN+PsLyPpTuPz4c+I7v4OwaNyXNGoZpKfcexnXX74FkRT
kVN2iBF55GGuTdU1ecUC3GhaeCj3SgX87yK3xA8OFmONwBpeoFeiQG+PIbLXufXa
zhingucFYIU3oxwOkN1/8gRF61gQQ9zh+8zzY01jz8Kz6re7XVM2+w26/Zcn1g0=
=ZY/A
-----END PGP SIGNATURE-----