I'm aware of the package architecture around MSYS2, and probably I will end up using it fully one day. I started this document years ago when trying to compile GraphicsMagick on Windows with MinGW64 and it is essentially my personal notes made public, a learning exercise playing with different version of gcc and Qt. I'm a Java developer and not a C++ expert so it may contains errors.
While I fully see the benefit of having a standard solution, I do like the freedom of using an ad-hoc solution when I have to balance between speed and size, or when I want to experiment with different package versions or simply different flags. Compiling Botan for example is an exercise of features against DLL size. Same story using ICU and QT.
It's not my intention to start a new MSYS2 or to create a yet another distribution, and I hope you may find something useful in it.
Take care,
Giovanni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's fine Giovanni, no offence was taken. I guess I'm sensitive to people not taking full advantage of MSYS2. In some cases I think this is because having a cohesive system of shared packages is very unfamiliar territory on Windows (though maybe some people just don't like MSYS2!). Once people dive in and engage with using and improving the PKGBUILD recipes, everyone using them benefits and Windows works a lot more like a Linux distribution, finally (ArchLinux mostly).
Regarding feature size vs DLL size, my opinion is that memory and storage are always increasing (it's developer time that's the premium) and more importantly because MSYS2 adopts FHS, we share those DLLs between many running programs, so we'll always bias towards the features side of that equation. For example, if you run 3 different Qt programs all independently built outside of MSYS2, then you will have 3 copies of the Qt DLLs in memory.
Finally, as to "a new MSYS2", personally I would not mind to see some innovation beyond what we've done; something with the Nix package manager (using Windows-native symlinks) or a port of Mac OS X's Homebrew project for example. I guess it could split the small MSYS2 community a little, but we'd still be able to share patches and knowledge.
Last edit: Ray Donnelly 2015-02-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ray,
just to let you know that I started taking full advantage of MSYS2 packages. Easy to install and to work with using both 32 and 64 bits compilers.
What can I say, mine was a good learning exercise anyway. I will try to learn a bit more about PKGBUILD and if I can contribute I will.
Thanks,
Giovanni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ray and Alexey,
I'm aware of the package architecture around MSYS2, and probably I will end up using it fully one day. I started this document years ago when trying to compile GraphicsMagick on Windows with MinGW64 and it is essentially my personal notes made public, a learning exercise playing with different version of gcc and Qt. I'm a Java developer and not a C++ expert so it may contains errors.
While I fully see the benefit of having a standard solution, I do like the freedom of using an ad-hoc solution when I have to balance between speed and size, or when I want to experiment with different package versions or simply different flags. Compiling Botan for example is an exercise of features against DLL size. Same story using ICU and QT.
It's not my intention to start a new MSYS2 or to create a yet another distribution, and I hope you may find something useful in it.
Take care,
Giovanni
That's fine Giovanni, no offence was taken. I guess I'm sensitive to people not taking full advantage of MSYS2. In some cases I think this is because having a cohesive system of shared packages is very unfamiliar territory on Windows (though maybe some people just don't like MSYS2!). Once people dive in and engage with using and improving the PKGBUILD recipes, everyone using them benefits and Windows works a lot more like a Linux distribution, finally (ArchLinux mostly).
Regarding feature size vs DLL size, my opinion is that memory and storage are always increasing (it's developer time that's the premium) and more importantly because MSYS2 adopts FHS, we share those DLLs between many running programs, so we'll always bias towards the features side of that equation. For example, if you run 3 different Qt programs all independently built outside of MSYS2, then you will have 3 copies of the Qt DLLs in memory.
Finally, as to "a new MSYS2", personally I would not mind to see some innovation beyond what we've done; something with the Nix package manager (using Windows-native symlinks) or a port of Mac OS X's Homebrew project for example. I guess it could split the small MSYS2 community a little, but we'd still be able to share patches and knowledge.
Last edit: Ray Donnelly 2015-02-12
Hi Ray,
just to let you know that I started taking full advantage of MSYS2 packages. Easy to install and to work with using both 32 and 64 bits compilers.
What can I say, mine was a good learning exercise anyway. I will try to learn a bit more about PKGBUILD and if I can contribute I will.
Thanks,
Giovanni