On 26/05/13 04:34, Renato Silva wrote:
> Then why not just stop build? Why not say, we do not support newer GCC
> versions in Cygwin (they don't currently work anyway, due to unrecognizing
> that flag). Something like this pseudocode:
> if --compiler=mingw32
> if gcc.from.mingw
> just compile
> else # from cygwin
> if gcc.major.version < 4 # like you said in the Python issue
This is absolutely the wrong way to tackle this; in 99.999% of cases,
checking for a specific version, or version range, of *any* tool is the
worst possible choice you could make.
> current code, continue passing -mno-cygwin
> abort saying "we do not support GCC from 4.x on under Cygwin"
>> Any particular package may depend on a particular version of MinGW
Why? It may depend on a specific *feature* of gcc, but to deduce the
availability of such a feature on the basis of a version check is quite
simply STUPID IN THE EXTREME.
>> It is not the job of distutils to decide which versions are
>> generally acceptable.
Quite. It should be checking for feature support, *not* for any
particular minimum *version*.
>> Although in practise the need to link against
>> the appropriate msvcrxx.dll means that you need a sufficiently new
>> version of MinGW for any given Python version.
Rubbish! If you need anything which isn't MSVCRT.DLL, then your
application is non-free, and needs an appropriate version of MSVC.
MinGW allows you to build non-free code, but this isn't something we
encourage. We may offer you the import libs to facilitate your
endeavour, but it's your responsibility, (or your end users'), to
furnish the necessary non-free MSVC DLLs. However, the ability to make
your application non-free, in this manner, isn't tied to *any* version
of MinGW's gcc; it depends solely on the version of mingwrt furnishing
the appropriate import libs, (and on your licensing provisions for
distribution of, and/or your end users' willingness to obtain and/or
deploy those non-free DLLs); you *cannot* predicate this on the basis of
*any* gcc version check, (and this is why version checks, in general,
are so fundamentally *wrong*).
> BTW what you said there in the Python issue confused me. GCC 4.x does not
> accept -m-no-cygwin in Cygwin, but in MinGW it was removed only in 4.5 or
> 4.6? But didn't folks here say they didn't touch anything about such flag
> here in MinGW? Can someone clarify this?
Cygwin discontinued infrastructure support, when they moved from GCC-3.x
to GCC-4.x; upstream GCC removed option support later.