-----Original Message-----
From: bulk88
Sent: Friday, January 09, 2015 4:16 PM
To: module-authors@perl.org ; perl5-port...@perl.org
Subject: name for a Module to build XS with Visual C on a core Mingw GCC
Perl
ActivePerl in 5.16 and before had code to build XS modules with
dmake/mingw/gcc, while the perl core was compiled with Visual C.
The same could also be achieved using ExtUtils::FakeConfig.
Going the other way, Visual C extensions with a GCC core has never been
done.
I thought that ExtUtils::FakeConfig would be able to accommodate that, too.
However, I could be wrong about that. It was certainly written mainly so
that its author could use dmake/mingw with msvc6-built ActivePerl.
I've managed to get 1 XS module to compile and run with a VC XS DLL and a
GCC Perl interp DLL and a couple things XSUBs ran flawlessly. So what
should be the name of this module? "VCConfig" in the root namespace?
Win32::VCConfig? Win32::Config?
Win32::VCConfig sounds good to me if you don't want to venture into the
ExtUtils::FakeConfig namespace.
Bear in mind that the mileage that the msvc6-built ActivePerls achieved with
MinGW was attributable to both MSVC-6 and MinGW using the same runtime
(msvcrt.dll).
If different runtimes are used (as might happen with your other-way-about
configuration) then you can run into problems - eg when a handle that has
been created by one runtime gets passed to the other runtime (whereupon the
"other" runtime says "wtf is this ?" and promptly crashes).
From memory, Win32::SharedFileOpen was unusable if the compiler that built
it used a different runtime to that used by perl.
Cheers,
Rob
