<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19019"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=750171721-06042011><FONT color=#0000ff
size=2>I also like the idea and I already created an emerge-target for
libsdl-src (just because it was the first thing that came into my
mind)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=750171721-06042011><FONT color=#0000ff
size=2>The patch is in the KDE reviewboard (which is down atm so I can't post a
link), any comment on it would be welcome</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=750171721-06042011><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=750171721-06042011><FONT color=#0000ff
size=2>-Michael</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Andrius da Costa Ribas
[mailto:andriusmao@gmail.com] <BR><B>Sent:</B> Wednesday, April 06, 2011 4:32
AM<BR><B>To:</B> KDE on Windows<BR><B>Subject:</B> Re: Emerge as an open
package manager?<BR></FONT><BR></DIV>
<DIV></DIV>
<P>1+</P>
<DIV class=gmail_quote>Em 05/04/2011 21:48, "Romain Pokrzywka" <<A
href="mailto:romain.pokrzywka@kdab.com">romain.pokrzywka@kdab.com</A>>
escreveu:<BR type="attribution">> <BR>> On Thursday 31 March 2011
09:30:11 Pau Garcia i Quiles wrote:<BR>>> Hello,<BR>>><BR>>>
What do you think?<BR>>><BR>>> <A
href="http://www.elpauer.org/?p=687">http://www.elpauer.org/?p=687</A><BR>>><BR>>>
Copying and pasting for the sake of easier discussion:<BR>>><BR>>>
--8<----<BR>>><BR>>> A while ago I said Koen from Emweb made an
interesting proposal at<BR>>> FOSDEM about emerge, the KDE Windows build
tool.<BR>>><BR>>> Yesterday, Jarosław Staniek and I reaffirmed our
commitment to<BR>>> ‘emerge’. Today, I’d like to go a bit further: let’s
bring more<BR>>> developers to emerge by opening it up to other
projects. Keep reading!<BR>>><BR>>> What is emerge, why is it
important and what was Koen’s proposal?<BR>>><BR>>> Fact:
Microsoft Windows is very different to Unix in regards to<BR>>>
development.<BR>>><BR>>> On Unix platforms -that includes Linux
and Mac OS X-, software<BR>>> isusually installed to /usr: applications
in /usr/bin and /usr/sbin,<BR>>> libraries in /usr/lib, headers in
/usr/include, common resources in<BR>>> /usr/share, etc. Also,
dependency management is usually something you<BR>>> can count on: when
you install kdelibs5-dev in Ubuntu, it will<BR>>> automatically install
libqt4-dev, kdelibs5-data, libfreetype<BR>>> (runtime), etc That makes
setting up a development environment a very<BR>>> easy task: look for
shared libraries, header files, etc in the common<BR>>> places and you
will probably find them.<BR>>><BR>>> On Windows there is nothing
like that. When you want to compile an<BR>>> application, you need to
provide (build and install) all its<BR>>> dependencies, and you need to
tell Visual Studio where to find<BR>>> everything. Even CMake usually
needs some help in the form of a hint<BR>>> for CMAKE_PREFIX_PATH. As
you may imagine, building KDE, which has<BR>>> more than 200 third party
dependencies and tens of modules (and with<BR>>> the move + split to
git, many more) becomes an almost insurmountable<BR>>>
task.<BR>>><BR>>> ‘Emerge’ to the rescue: inspired by Gentoo‘s
emerge, Ralf Habacker,<BR>>> Christian Ehrlicher, Patrick Spendrin and
others (yours faithfully<BR>>> included) developed a tool which
downloads the source, configures,<BR>>> builds, installs and packages
KDE and its dependencies. It makes a<BR>>> world of difference when
building KDE. Actually, it makes building KDE<BR>>> on Windows possible.
Once more: thank you very much guys, impressive<BR>>>
tool.<BR>>><BR>>> There are two well-differentiated parts in
emerge, the ‘engine’ and<BR>>> the ‘recipes’.<BR>>><BR>>>
The ‘engine‘ takes care of downloading the sources (tarballs,<BR>>>
checkouts from Subversion and git clones, etc) , configuring and<BR>>>
building for the usual build systems (QMake, CMake, NMake
makefiles,<BR>>> etc), installing, bundling packages together and much
more. All that<BR>>> for four compilers (MSVC2008, MSVC2010, MinGW32 and
MinGW-W64). It’s<BR>>> the equivalent to Gentoo‘s emerge, Debian‘s dpkg
+debhelper/cdbs or<BR>>> Homebrew and MacPorts for
Macintosh.<BR>>><BR>>> The ‘recipes’ are the package-specific
“instructions” a particular<BR>>> piece of software needs to build:
what’s the name of the tarball? URL<BR>>> to download from? What
versions are available? What build system to<BR>>> use to configure and
build? Does it need any Windows-specific patch?<BR>>> They are written
in Python using some helper modules ‘emerge’ provides<BR>>> (the
debhelper-like part I mentioned above).<BR>>><BR>>> Currently,
there are about 70 recipes in emerge, organized in our<BR>>> ‘portage
tree’ (bear in mind the names are taken from Gentoo but the<BR>>>
internals of the tool are completely different). With those 70<BR>>>
recipes, we are able to build most KDE modules. Problem is to
provide<BR>>> all the optional features, we are missing probably 200 to
250 more<BR>>> recipes. Given that KDE on Windows is quite short on
developers, we<BR>>> have to decide: either we fix bugs and improve the
integration of KDE<BR>>> on Windows, or we keep track of the
dependencies. I won’t lie: for KDE<BR>>> on Windows, I’d rather focus on
development than on packaging.<BR>>><BR>>> Given that writing and
maintaining recipes does not strictly require<BR>>> programming skills
(although they help ), during my talk at FOSDEMI<BR>>> kept asking
people to join the KDE on Windows team as packagers, even<BR>>> if you
know little to nothing about software development. If you think<BR>>>
about it, that’s what we have in Linux distributions: there are<BR>>>
hundreds (thousands?) of packagers in Debian, Fedora, openSuse,
etc<BR>>> which take care of the ‘recipes’ to build software developed
by<BR>>> someone else (‘upstream’, in the parlance). What we have in KDE
on<BR>>> Windows, where we are the KDE packagers, the KDE developers
(upstream)<BR>>> and the emerge developers, is actually an
anomaly.<BR>>><BR>>> Then Koen took the microphone and said: why
don’t you open emerge to<BR>>> other projects?<BR>>><BR>>>
And I there I realized he was damn right<BR>>><BR>>> We have
developed an awesome tool to download, configure, build,<BR>>> package
and install third party software on Windows, to manage<BR>>>
dependencies, to update, etc. For four compilers, no less. The<BR>>>
‘engine’ of emerge is not really tied to KDE. We already have a lot
of<BR>>> recipes for software which is not KDE specific: openssl, Qt,
bzip2,<BR>>> libpng, mysql, etc.<BR>>><BR>>> I see no actual
reason to disallow Gnome, GStreamer,OpenSceneGraph,<BR>>> LibreOffice
and many others in (assuming someone wants to take care of<BR>>> them,
of course – no, do not look at me! I don’t have time!).<BR>>> Currently,
the only ‘barrier’ preventing those recipes in is ‘emerge’<BR>>> is
developed in the KDE repository and you need a KDE developer<BR>>>
account to commit your recipes. That’s about it.<BR>>><BR>>> There
is also a ‘perception’ problem: “if emerge is developed in KDE,<BR>>>
it’s because it’s a KDE-thingy, right?”. Well, no. One way to
avoid<BR>>> that would be to graduate emerge from KDE and make it an
independent<BR>>> project, one in which the current developers have
accounts, and new<BR>>> developers get an “emerge project” account
instead of a KDE account to<BR>>> commit recipes. Please note
“graduating” does not mean “expelling”,<BR>>> “firing” or anything
peyorative. It does not mean that ‘emerge<BR>>> developers’ (engine and
recipes) are worse than KDE developers, or<BR>>> less KDE developers
than our god David Faure: in KDE, we consider<BR>>> Debian, Fedora,
openSuse, etc KDE packagers as equals, they are also<BR>>> KDE
developers and many of them are in the KDE eV(funny thing is I am<BR>>>
not).<BR>>><BR>>> My wish for today: think of one application or
library you’d like to<BR>>> see in Windows and become its maintainer in
emerge for Windows.<BR>>><BR>>> For now, let’s do this in the
kde-windows mailing list and if this<BR>>> idea succeeds, then we’ll
talk about graduating. You could also try to<BR>>> add support for a new
compiler (OpenWatcom, Intel C++, etc) but that’s<BR>>> a lot more more
and it’s not a priority now.<BR>>><BR>>> PS: Yes, I know about
CoApp, Microsoft‘s similar effort, with some<BR>>> magic involved. I’ve
been watching and trying it since day 1. I’m<BR>>> really interested.
It’s just not there yet and I do not have spare<BR>>> time to
helpGarrett (hey Microsoft, hire me and I’ll have all the time<BR>>> in
the world! )<BR>>><BR>>> --8<----<BR>>><BR>>>
--<BR>>> Pau Garcia i Quiles<BR>>> <A
href="http://www.elpauer.org">http://www.elpauer.org</A><BR>>> (Due to
my workload, I may need 10 days to answer)<BR>>>
_______________________________________________<BR>>> Kde-windows
mailing list<BR>>> <A
href="mailto:Kde-windows@kde.org">Kde-windows@kde.org</A><BR>>> <A
href="https://mail.kde.org/mailman/listinfo/kde-windows">https://mail.kde.org/mailman/listinfo/kde-windows</A><BR>>
<BR>> I don't know if other people have commented on the blog page instead,
but as far as I'm concerned I find the idea to <BR>> make complete sense
and be technically doable. <BR>> <BR>> Indeed a first good step towards
opening emerge to non-kde communities would be to move it to an independent
repository. <BR>> The question is which one :)<BR>> <BR>> Anyway FWIW
I like the idea!<BR>> Cheers<BR>> <BR>> -- <BR>> Romain Pokrzywka
| <A href="mailto:romain.pokrzywka@kdab.com">romain.pokrzywka@kdab.com</A> |
Senior Qt Software Engineer & Trainer<BR>> Klarälvdalens Datakonsult
AB, a KDAB Group company<BR>> Tel. Sweden (HQ) +46-563-540090, USA
+1-866-777-KDAB(5322)<BR>> KDAB - Qt Experts - Platform-independent
software solutions<BR></DIV></BLOCKQUOTE></BODY></HTML>