From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 629397F6CB for ; Wed, 28 Jan 2015 11:45:00 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7BgAMvchU/5NHeVtagwYiMFmDAIkfuWgKhwpDAQEBAQF9hDZLOAgCBRMOAhEFGB0BRIgSCbAUj0iVS4EhiG2FCBEBgwQMLxEdgRMFkjmCDYNIAYEVNoo+hjMigUUMAWCBPT0xgQuBNwEBAQ X-IPAS-Result: A0A7BgAMvchU/5NHeVtagwYiMFmDAIkfuWgKhwpDAQEBAQF9hDZLOAgCBRMOAhEFGB0BRIgSCbAUj0iVS4EhiG2FCBEBgwQMLxEdgRMFkjmCDYNIAYEVNoo+hjMigUUMAWCBPT0xgQuBNwEBAQ X-IronPort-AV: E=Sophos;i="5.09,480,1418079600"; d="scan'208";a="97976212" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 28 Jan 2015 11:44:59 +0100 Received: by nautica.notk.org (Postfix, from userid 1003) id 86DA9C009; Wed, 28 Jan 2015 11:44:58 +0100 (CET) Date: Wed, 28 Jan 2015 11:44:58 +0100 From: Adrien Nader To: caml-list@inria.fr Message-ID: <20150128104458.GC5338@notk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Caml-list] [ANN] Win-builds 1.5.0 - fully-bootstrapped free software distribution for Windows [ 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. -- Adrien Nader http://win-builds.org