[Module-build-general] [PATCH] Compiling under Windows

[Randy W. S. <Ra...@Th...>]

I've included the complete file instead of a patch since the original is 
just an empty skeleton file. M::B now successfully compiles under 
Windows, and it passes all tests (most of the time, see below). It could 
stand to be tightened up a bit, but I said I'd submit it by the weekend, 
and I'm pretty much out of time :). It works fine; it's just that there 
is some duplication of code which could probably be eliminated.

It's a bit more code than I first anticipated, but I thought it might be 
worthwile to take advantage of the fact that most compiler/linkers can 
be scripted. When possible it writes compiler/linker options to a file 
instead of the commandline; this will hopefully avoid problems with some 
versions of the Windows shell that have limits on commandline length. 
I've set this up so that an option can be easily added to turn it on or 
off if desired.

Outstanding issues:

The 'runthrough.t' test sometimes fails in random places at random 
times. This is true with or without the modifications I've made. 
Sometimes 2 tests fail, sometimes 5, sometimes ??, most of the time 
none--It's completly unpredictable. It happens after ./build (real)clean 
as often as it happens after back to back runs of ./build test. I have 
not yet had a chance to look into it, but I'm pretty certain of the 
cause. Windows seems to be extremely sensitive about file operations. 
Sometimes a file gets locked (not always the same one in this case), and 
it can no longer be accessed. This usually means that a file handle was 
not explicitly closed or a tied file was not untied, etc.

Another place I ran into problems with locked files is with the 
'system()' call. My first stab at getting M::B to work was basically a 
copy, paste, and edit of the 'compile_c()' and 'link_c()' routines in 
Base.pm, with branches all over the place to handle differences in 
compiler syntax. When passing a LIST to system(), It would compile, but 
the next call to system() to invoke the linker would fail with an 
'access denied' error. If I joined the list into a single string it 
would work (don't ask how long it took me to track that down to the 
system() call). At some point I decided to revisit the issue to figure 
out exactly what was happening, unfortunatelly changing back to the LIST 
form now works as expected--It has never failed with that error again. 
This was after I restructured the code, so I can only assume... bah, I 
won't assume anything.....

Under Windows, the ExtUtils::Mksymlist module is required to generate a 
file that instructs the linker on what functions/variable to 
export/import. Most of the time it is invoked with just the name of the 
module being built, but sometimes it's neccessary to pass in lists of 
functions/variables. I thought it would be best to leave it to you as to 
  how the user will pass the information through. As it is, it should 
work for most modules, and a small change to 'sub prelink()' telling it 
where to get the user supplied options will allow it to work those 
modules that need that extra functionality.

If the xs.t test fails to find a compiler, Shouldn't it NOT fail, but 
simply notify the user that there is no compiler and that it will 
operate in a degraded capacity, i.e. only installing pure perl modules?

The first of the week is always pretty busy for me, but I'll try to look 
into some of the outstanding issues later this week.

Randy.