On Tue, 15 Nov 2005, Sisyphus wrote: > > * On Windows ActivePerl will automatically use MinGW to compile modules > > if Microsoft VC++ is not installed, but MinGW and dmake are. > > Excellent move !! > > Presumably a fresh Config.pm, containing values appropriate for MinGW/dmake, > gets written first time you try to build an extension.
No. The correct values are determined dynamically at runtime. You can switch between VC++ and MinGW as much as you want to by putting VC++ on the PATH or removing it. The configuration files will not be altered. We do something similar on Unix where we supply both statically and dynamically linked versions of Perl. You can run both at the same time from the same tree and the Config.pm values will be correct for both processes. This wouldn't work if we modified Config.pm and friends on disk. (Windows and OS X only have dynamically linked Perl, so this doesn't apply there). > How did you get around the problem that there's no 'libperl58.a' ? > ExtUtils::FakeConfig solves this problem by building a 'libperl58.a', > but it occurs to me that since gcc can link directly to a dll, it is > perhaps unnecessary to create a 'libperl58.a' at all. Rather, simply > modify the appropriate Config.pm values so that gcc does, in fact, > link directly to 'perl58.dll'. > > I just tested that concept out by building Math::FFT (having renamed > 'libperl58.a' so it couldn't get found), and linking directly to > 'perl58.dll' worked fine. However, I can't provide any arguments in > support of doing it that way (as opposed to the > 'ExtUtils::FakeConfig' way). > > In addition, faik, that approach might not work *all* of the time, and > I'm not even sure that it can be effected simply by amending Config.pm > values - there may be some EU::MM amendments necessary, too. We link directly against perl58.dll. We have tested our current setup with a large list of CPAN modules, and haven't found any that would build with VC++ but not with MinGW. If you find any, please let me know and we'll investigate how we can fix that. However, there are lots of modules that don't compile on Windows at all, even with VC++. They will most likely not compile with MinGW either, and I'm not interested in hearing about those, as they are just not compatible with Windows at all as far as I'm concerned and you should talk to their authors instead. :) I still recommend to compile modules with VC++ 6.0 instead of MinGW if you own a copy of VC++ 6.0, as the compiler is faster *and* generates faster code (at least the last time I checked; I haven't been running benchmarks lately). We just wanted to support MinGW as a free alternative for people who want to compile modules themselves and don't have access to VC++ 6.0. Cheers, -Jan _______________________________________________ Perl-Win32-Users mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
