From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id DE8187F6CC for ; Wed, 28 Jan 2015 12:03:26 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=pra; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=mailfrom; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.tu-berlin.de) identity=helo; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="postmaster@mail.tu-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BlAQClwchUnCEHlYJag1hZgwDBTAqFcQKBF0MBAQEBAREBAQEBAQgLCQkULoQNAQUjDwE7ChELEggCBRYLAgIJAwIBAgE3AQ0TBgIBARqIDgQJv1mVSoEhiG2FCBEBHTqCLQwvEYEwBY0NhSyCDYReNoRmhViCdoM9gXMwHRSBPW6BC4E3AQEB X-IPAS-Result: A0BlAQClwchUnCEHlYJag1hZgwDBTAqFcQKBF0MBAQEBAREBAQEBAQgLCQkULoQNAQUjDwE7ChELEggCBRYLAgIJAwIBAgE3AQ0TBgIBARqIDgQJv1mVSoEhiG2FCBEBHTqCLQwvEYEwBY0NhSyCDYReNoRmhViCdoM9gXMwHRSBPW6BC4E3AQEB X-IronPort-AV: E=Sophos;i="5.09,480,1418079600"; d="scan'208";a="119001060" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jan 2015 12:03:22 +0100 X-tubIT-Incoming-IP: 91.64.130.234 Received: from ip5b4082ea.dynamic.kabel-deutschland.de ([91.64.130.234] helo=[192.168.178.31]) by mail.tu-berlin.de (exim-4.72/mailfrontend-6) with esmtpa for id 1YGQP2-0005bA-5b; Wed, 28 Jan 2015 12:03:21 +0100 Message-ID: <54C8C1F8.8040803@tu-berlin.de> Date: Wed, 28 Jan 2015 12:03:20 +0100 From: =?UTF-8?B?Q2hyaXN0b3BoIEjDtmdlcg==?= Organization: Technische =?UTF-8?B?VW5pdmVyc2l0w6R0IEJlcmxpbg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20150128104458.GC5338@notk.org> In-Reply-To: <20150128104458.GC5338@notk.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.28.105119 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: Re: [Caml-list] [ANN] Win-builds 1.5.0 - fully-bootstrapped free software distribution for Windows -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting! Maybe this is a stupid question but given that you use OCaml for implementing and there is still no way to distribute opam packages for windows, could you not package ocaml/opam for your distribution and this way import all ocaml packages at once? Am 28.01.2015 um 11:44 schrieb Adrien Nader: > [ This email is posted to several mailing-lists: win-builds', > mingw-w64 and the caml-list. ] > > Hi, > > I am happy to announce the availability of Win-builds 1.5.0 which > is the result of many months of work in order to add new packages, > update available ones and make all operations simpler and more > intuitive. > > Homepage: http://win-builds.org Downloads: > http://win-builds.org/download.html Documentation: > http://win-builds.org/documentation.html Support information (IRC, > MLs): http://win-builds.org/support.html Package list > (informative): http://win-builds.org/packages.html Source: > http://cgit.notk.org/gitolite/win-builds/ > > === Project Description === > > Win-build is best described as a free software distribution for > Windows: the goal isn't to provide dumps of binaries but to build > something new, well-integrated, easy to install and upgrade, > focused on stability (but without being out-of-date either), with a > good package coverage and identical binaries on Windows and Linux. > > === New in 1.5.0 === > > Complaints for the previous version centered around simplicity and > package coverage. As such, this new version has focused on making > it simpler to edit packages (modifying existing packages or adding > new ones) and install thanks to more automated build steps on Linux > and to the re-introduction of a GUI on Windows. > > ==== New Packages ==== > > The package count has risen to 90. This may seem low compared to > Linux distributions but this is enough to build GUI applications > using either the EFLs, Qt and GTK+ (and many more). This makes a > lot of sense if you consider how many packages on Linux make little > sense on Windows: smartd, pciutils, all the X-related ones, KDE and > Gnome, motif, mt, ... > > ==== GUI Package Manager and Installer on Windows ==== > > The GUI is written using ocaml-efl and is used as the installer on > Windows. The actual executable relies on several dozens of files > (libraries and resources) and is packed into a self-extracting > (and cleaning) executable to make it appear as a single file that > can be readily run[1]. Its build is not documented for this release > as a sign that the ocaml cross-compiler has some quirks[2]. Getting > full and upstream support for cross-compilation is however > something I'll be working on from now on. > > ==== More Scripted Installation on Linux ==== > > On the developer side, the component that runs all the build > scripts has been rewritten from shell script to OCaml. This > provides a simple validity check of the build list description and > proper ordering of the build steps, making it safer for people to > do their own edits. > > To honor the great tradition of OCaml programs taking advantage of > high-level optimizations, doesn't attempt to build several packages > in parallel for a given architecture. It however builds for two > architectures in parallel, thereby providing a reasonable > efficiency. > > ==== Documentation ==== > > Documentation has been updated and expanded. It finally properly > covers the topic of creating new packages and is therefore now > fairly exhaustive when it comes to the win-builds project. > > Over the next few days, the documentation will be expanded again > to cover more topics related to usage on Windows, in particular > with IDEs. > > === Post-mortem and Future === > > This release took much longer than planned. Roughly twice as long. > This is due to two factor: adding the GUI for the package manager > and installer which was planned for the subsequent version, and > Qt. > > The GUI seems to have been worth it with much better download > stats and close to a hundred installations per day (more than > +40%), without additional publicity. [these numbers are guaranteed > and not inflated by anything] > > Qt will be dealt with in a dedicated section below. > > ==== -next repository ==== > > The work leading to this version, as is most often the case, has > made apparent a number of issues with the development process. The > main issue is probably the time it takes between the addition of a > feature request and the availability of the corresponding package. > > This has little to do with the actual packaging or updating work > and almost everything to do with the lack of a repository for the > next version. As such, starting with the first changes after 1.5.0, > there will be a "-next" version that will be regularly updated with > packages built from the latest code and publicly reachable. > > ==== New contributions: what has been done and what's coming up > ==== > > A number of new contributors and contributions have appeared. Most > changes were fairly late in the development cycle and have > therefore not been merged in the main tree for 1.5.0. > > The code hosting has been moved to a gitolite in order to allow > hosting of branches from others. This is for added convenience and > any publicly-reachable git hosting is fine for merging back to the > main branches. > > ===== Qt ===== > > Some packages unfortunately require a lot of work with each new > version. Actually the set of such packages has only one inhabitant: > Qt. > > I'll be frank: maintaining a Qt that is cross-compiled from Linux > for Windows is probably close to a full-time part-time job, i.e. > something that will take all the time for someone doing part-time > on it. My perception is probably flawed since I've made the initial > packaging and it includes things that have probably never been done > before and definitely deviate from what upstream had in mind (i.e. > cross-compile qmake itself). > > It is also unfortunately to be expected that each new version of > Qt breaks something for this packaging (cross-compile to Windows). > > As such, additional maintainers are looked for. There is no reason > to be afraid and this is not about abandoning the package unless > someone steps up. This is entirely in order to be able to better > track upstream releases. > > ==== Security Updates ==== > > This part has mostly been a failure. The work involved was larger > than expected and was let slip by without bound. > > Basically, the work (reading, updating the source, rebuilding, > testing, uploading, announcing) is sometimes too much to do > immediately after the availability of a security fix. With no > strict bound and with the need to spend time on large changes in > the build architecture, the updates have slipped by one day at a > time. As usual, Frederick P. Brooks got it right: Q: How does a > large software project get to be one year late? A: One day at a > time. > > The larger architecture have been done. There will be others but > they should be less pervasive and shouldn't block working on other > tasks for as much time. > > More importantly, at least for this release, the official goal is > to handle most security updates in 3 days at most and let none slip > by more than 8 days. This should be at least as good as most large > Linux distributions. Any security update lagging behind for more > than that should be considered "unnoticed" and a poke warranted. > > > PS > > [1] It obviously takes some time to extract the 25MB or so (8MB > compressed) but it is fast enough and can most probably be made > faster. The main advantage however is that this solves the issue of > replacing files which are in-use: the package manager depends on > .dll files and therefore would have been unable to ever replace > these without resorting to complex tricks. > > [2] Perhaps the best proof is the following top-level code: let > init_count = ref 0 let init () = if !init_count = 0 then ( > do_the_actual_init (); incr init_count; ) else () let () = init () > > On Windows I had to add an explicit call to the "init" function > from somewhere else in the code. > - -- Christoph Höger Technische Universität Berlin Fakultät IV - Elektrotechnik und Informatik Übersetzerbau und Programmiersprachen Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin Tel.: +49 (30) 314-24890 E-Mail: christoph.hoeger@tu-berlin.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTIwfgACgkQhMBO4cVSGS/VpwCfbnofOuJM1mvoV6p6X2RtwmeC 92AAoJ7ywnbt6D2QnPPZ06P6EDZk20Lo =GlOv -----END PGP SIGNATURE-----