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