Hello, Mario. Currently, I'm working on making a set of recipes using the Nix functional package manager that will let me compile native software for Windows. Nix has its own language for specifying how to build software and *compositions* of software. The recipes are typically stored in a Git repository. The nixpkgs repository, for instance, has thousands of recipes for software in it and there are hundreds of users actively working on it:
https://github.com/nixos/nixpkgs For people desiring stability, with Nix, you don't have to rely on a central package repository: when you build a piece of software, you get exactly what was specified in the local Nix recipes on your computer. These recipes specify exactly how to build all the dependencies of your software, including the compiler toolchain. So, you will almost always be able to rebuild all of the software you depend on, as long as you keep track of those recipes (e.g. in Git). Of course, it would be very slow to rebuild compiler toolchains every time you wanted to build a package. Nix speeds things up for you in several ways. First of all, builds are identified with long hash codes that take into account everything about the build and its dependencies. The hash codes are used as a key for a local cache on your computer called the Nix store (/nix/store/) so you don't have to build software that you already have. There is also a centralized binary cache that is built from the nixpkgs repository so you don't have to compile a lot of things yourself and can just download them instead, as long as the download was built in exactly the same way as the recipe on your computer. Because of the hash code, Nix can tell if you change any of the recipes for the software you depend on. The next time you build your software, Nix will know to rebuild the changed package and everything that depends on it. Compared to pacman, this causes lots of unneeded rebuilding, but it gives us a lot more confidence that the final software will work correctly, instead of failing because some DLL name changed or a library's ABI changed. Since Nix does not run in Windows, I would be cross-compiling from Linux to Windows. Nix could probably work inside the Windows Subsystem for Linux, which would allow us to easily run test suites for the software we compile, but I have not looked in to that. The nixpkgs repository itself has support for cross-compiling to Windows but I get the impression that it's not very good, because the main toolchain does not even have winpthreads, and thus things like std::future do not work. Ericson2314 on GitHub has made a bunch of pull requests to clean up the architecture for cross-compiling recently. But the way that they build GCC and other things in nixpkgs is so complicated that I think I'd like to try writing my own expressions. I have succeeded in making a mingw-w64 cross-compiler and compiling some console apps for Windows, like the pdcurses demos. My recipes are here: https://github.com/DavidEGrayson/nixcrpkgs Feel free to email me privately if you want to try out nixcrpkgs and want some help getting set up. --David Grayson On Wed, Sep 21, 2016 at 3:04 AM, Mario Emmenlauer <ma...@emmenlauer.de> wrote: > > Hi, > > anything I can do to get started? Any pointers how your current > continuous integration system works? Somebody mentioned that the > CI on github is broken a while ago, is that still true? > > Cheers, Mario > > > On 30.08.2016 13:27, Mario Emmenlauer wrote: >> On 30.08.2016 13:06, Alexpux wrote: >>>> 30 авг. 2016 г., в 11:16, Mario Emmenlauer <ma...@emmenlauer.de> >>>> написал(а): >>>> >>>> I was wondering if people would like to have a "stable" repository? >>>> >>>> I was thinking that when a plateau is reached (majority of packages >>>> compiles fine), the current snapshot could be copied to stable. In my >>>> eyes, the essential requirement would be that all base packages compile >>>> fine. Everything else could be handled a bit ad-hoc. >>> >>> >>> Hi, Mario! >>> If someone want to support «stable» repo - we can talk about it. >>> There are some problem from my POV to support this. >>> 1. Who will decide that package is stable? >>> 2. You can’t just copy builded package from current repository and place it >>> «stable». You must rebuild it agains «stable» set of packages. >>> 3. Who will maintain all of this work? I will not do any work with this >>> sorry because my time is limited and now I have many other priorities than >>> MSYS2. >> >> I can maybe do parts of this work. My company has a bit of free >> resources. But you must help me understand what am I up against? >> What is your current build system? Is it Windows-based? How many >> resources does it need? What is the size of the package repository? >> How much traffic do you currently have? >> >> I have one idle build server (4 Core Xeon with 16GB Ram) that can >> host a build system. I guess "stable" does not change hourly, so >> maybe one machine is sufficient? My company webserver has 0.5TB of >> free disk, and 100MBit internet link in a good IT centre in Europe. >> I could host some packages, and maybe even your dokuwiki(?) > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Msys2-users mailing list > Msys2-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/msys2-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users
