El El mié, 1 feb 2017 a las 19:56, Eli Zaretskii <
eliz@gnu.org> escribió:
> From: Germán Diago <germandiago@gmail.com>
> Date: Wed, 1 Feb 2017 12:18:28 +0700
> Cc: guile-devel@gnu.org
>
> Well, provided that you are tied to msys and you can never ever compile guile with a microsoft compiler, that
> is ok. You are talking only about your use case. The reality is quite different: if you want windows adoption, you
> need to use the native toolchain to compile.
MSYS is used only to run Bash, m4, perl, etc. -- programs that are
invoked during the configure stage and by shell script fragments in
the Makefile. The compiler is MinGW, not MSYS. MinGW produces native
executables that are completely compatible with MSVC compiled
programs. So I don't see a problem here, or any need to use non-free compilers.
Good to hear it is compatible at least. I do not see the point in blocking users to use the compiler of their choice as long as you can still use your free compiler. Autotools is slow in windows as well I say this by own experience. Anyway I do not wanna get into ideological fights. If you are not willing to take positively suggestions and possible collaborations for potentially improving adoption, I do not wanna stay in your way. I think this attitude will harm more than benefit the project.
MinGW supports native Windows threads, and in fact the ported pthreads
are just a very thin wrapper around native threads.
This is not how most users use a setup in windows no matter how much we whine. This will prevent adoption. So if you want my help, I am still available. As I said, my proposal does not prevent you from using MinGW.
Thanks for your time.