Dear David, your suggestion and pointers are very very interesting, and I was admittedly completely ignorant of Nix until now! I will give it a closer look soon, but its something that will require a bit of learning on my side (or at least a review of my current work style) :-) :-)
All the best, Mario On 20.02.2017 17:20, David Grayson wrote: > 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(?) -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 München http://www.biodataanalysis.de/ ------------------------------------------------------------------------------ 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
