On 9. 3. 2015 2:07, David Marceau wrote: > You said "POSIX" a great deal. I understand it is important as it means > 100% UNIX behaviour in a sense. It seems to me GNU/Linux holds the > torch for POSIX. New stuff possibly going into POSIX will land in > GNU/Linux on experimental branches before anywhere else now.
While it is true that GNU/Linux is the leading open-source POSIX platform, there are other important ones, like Darwin (base of OS X) and BSD, also trying out new stuff which could make its way into POSIX specs. > http://en.wikipedia.org/wiki/POSIX > POSIX in my opinion is all that command-line and piping from one tool to > another is available both in cygwin and msys2. POSIX is all about > making sure app inter-client communication conforms to the same CLI apis > and C apis. Strictly speaking, there's no need to have an opinion about what POSIX is or isn't -- it's a standard. In practice, POSIX compliance is what makes porting fully-FOSS software between Linux, OS X and Cygwin easy. > The company "MKS SOFTWARE" claims POSIX compliance better than cygwin. > So does that mean the POSIX pecking order is "mks toolkit" > cygwin > > msys2 ? > http://www.mkssoftware.com/products/ First off, first three results from Google (including a comparison page on MKS website) don't say anything about MKS claiming (or actually having) better POSIX support than Cygwin <https://google.com/search?q=mks+vs+cygwin>. Could you link to a source of this information? MKS certainly boast their enterprise user support and QA, but not any technical superiority. I have not tried MKS or actually seen it running, but I read more about MKS compared to Interix and SFU/SUA than to Cygwin, which would hint at MKS being maybe faster than Cygwin, but nothing else. Also, since this is an enterprise product, I would guess that their packages get updated less often or with greater delays than in Cygwin. Your proposed ordering then doesn't seem to be supported by any proof. Cygwin and MSYS2 are on par with regard to POSIX compliance and MKS's position is unclear. >>From what I experienced recently, the gtk/gtkmm stuff in MSYS2 is seems > to stay closely up-to-date with arch sources unlike cygwin gtk/gtkmm > which for a while was quite dated when I last checked. There is no > gtk/gtkmm to be found anywhere mentioned on mkssoftware's product > offerings. They mentioned xserver and osf/motif. GTK runs on top of X, > but mks software should clearly state whether they support > kde/gnome/xfce on top of their xserver. They didn't so I am > disregarding the mkstoolkit because they are not providing a one-stop > place to find everything found in the most popular GNU/Linux distros. GTK can run on top of different display servers, including of course X, but also Win32 APIs and probably others. > I don't care about POSIX. I care about GNU/Linux. I am more focused > about GNU/Linux apps behaving correctly not only on GNU/Linux but also > on 64-bit Windows OS WITHOUT RELEARNING ANY RECENT WIN64 WINDOWS APIs to > get there. If I can get 64-bit GNU/Linux apps to build and run on a > windows os by using MSYS2/MINGW64, then I want to use it. Depending on what APIs the application uses, you may get lucky with mingw-w64 gcc, or need to use MSYS2 gcc. But then again, if you know you need POSIX, Cygwin should be the preffered choice. MSYS2 is not suited for building and distributing random POSIX software. > Although I'm brushing up on my c++/gtkmm skills intent on using them > with msys2/mingw64 and linux distros, I've been looking at the progress > being made with golang 1.5 to target many different os'es. One single > command gets your binary ready to run for another os. I've shown three > different commands to build and another three different commands to run > them on their respective os along with the output. golang is currently > more in favor of staticlib-based-binaries rather than dll-based-binaries. > http://dave.cheney.net/2015/03/03/cross-compilation-just-got-a-whole-lot-better-in-go-1-5 > > % env GOOS=darwin GOARCH=386 go build -x hello.go > # scp to darwin host > $ ./hello > Hello darwin/386 > > % env GOOS=linux GOARCH=arm GOARM=7 go build -x hello.go > # scp to linux host > $ ./hello > Hello linux/arm > > go build -x hello.go > [loongson@patience01 testx1]$ ./hello > Hello linux/amd64 > If you would like to see the noisy under-the-hood results for these > builds here they are: > https://github.com/golang/go/issues/10075 > > It may seem irrelevant, but when there is a working gtk3 binding > "gotk3", then it becomes relevant to building GNU/Linux GUI apps with > all the bells and whistles probably found within the above mentioned > POSIX. I recently saw a video about spec testing for http2 within golang. > https://www.youtube.com/watch?v=gukAZO1fqZQ > LOTS of state-of-the-art more-POSIX-than-POSIX stuff in golang. > The http2 golang test coverage stuff mentioned in the above http2 golang > talk youtube video demonstrates that. Now I'm just confused. How is GTK3 or HTTP2 related to POSIX? > I like the end-result of msys2/mingw and cygwin... > bringing linux tools guis to windows. > THE BETTER TOOLKIT will be the one that allows you to target everything: > -for MS-WINDOWS OS without learning anything MS win32/win64 specific. > -for ANDROID OS without learning anything ANDROID specific. > -for Apple MAC OS X without learning anything Apple specific. I agree and add one more: -for LINUX OS without learning anything Linux specific. > In a sense, that's what POSIX was for, but GUI wise the landscape is > foggy. X.org(latest)? Qt5? GTK3? For me GTK3 in c++(gtkmm) and > golang(gotk3) seem to lift the fog. msys2/mingw64 help to lift that fog > when targeting windows specifically. Installing packages with pacman is > better than installing packages with cygwin. I am in favor of a wiki > page helping to create msys2/mingw64 pacman packages ready to be > submitted to msys2/mingw64-specific repository mirrors. > > http://gtkmm-installation.blogspot.ca/2015/01/gtkmm-installation-on-windows-step-by.html > https://github.com/conformal/gotk3/issues/88 > > So where am I going with all this? It would be nice to see golang > well-supported within msys2/mingw64 infrastructure to get you where you > want to go faster. Some tools to help create packages ready to upload > to pacman msys2/mingw64 repositories for not only c++/gtkmm based > binaries, but also golang binaries would be awesome. Our repositories are not like the AUR, uploading is done only by core project members. Some PKGBUILD templates (for C++/gtkmm or go packages) would be nice to have, but especially go doesn't like to follow conventions, so packaging go and go packages is a bit difficult. Hopefully, I answered all your questions and provided useful input on your other points of discussion. -- David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
