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

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

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

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.

(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.)

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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20130506/a223b5cb/attachment.sig>