Hi all,

I really look forward to a *stable* msys2 repository.
Things are moving very fast with msys2 and while that
is great for having the latest and greatest it poses
problems with stability.

Currently, we basically freeze in SVN an installed msys2
version that builds (and runs) all our software and then,
after half a year or so, we try to build with a newer msys2
and update the current version to a new one if everything
works out. While this sort of works you don't get the
latest developments, bug fixes and so on very quickly.

Cheers,
Adrian Pop/

On 2/20/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(?)
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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
>


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

Reply via email to