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

[Ken W. <ke...@ma...>]

On Sunday, February 23, 2003, at 05:09  PM, Randy W. Sims wrote:

> 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).

Awesome, thanks!

> 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.

That can wait until the future.  To do this cleanly, I think we could 
create a module like ExtUtils::C with classes like 
ExtUtils::C::Compiler and ExtUtils::C::Linker that Module::Build could 
just use transparently.  Its purpose would be to compile and link 
things that will be linked in with Perl modules (not a general tool for 
arbitrary C code), using the same interface regardless of platform.

We could use that module in other situations too, like in the testing 
code for ExtUtils::ParseXS.

Probably the code you've written for Win32 and the code I wrote for 
Unix would be a good start toward such a module.  But given that the 
module doesn't exist yet, we'll just have to wait. =)

Also, I think a "uses-a" or "has-a" relationship to the compiler/linker 
would make more sense than the "is-a" relationship that's now in the 
M::B::P::Windows.pm code, but I understand that this was probably an 
easier way to get things written.


> 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.

Sounds good.

> 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.

Yes, there were a couple of places I had to deal with this problem for 
the Win32 folks.  Are you using the latest CVS version of M::B, or the 
CPAN version?  The CVS version fixed a few things, but it's likely 
there are more instances of this problem lurking.  Is there any way to 
get an error message to tell you what file is in contention?


> 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).

Ack - I'm really trying to avoid system(STRING) calls, because I really 
don't want shell metachars involved anywhere.  Differences in shell 
behavior can open up a whole new can of worms I'm trying to avoid.


> 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.....

We'll just keep our eye on it, I guess.


> Under Windows, the ExtUtils::Mksymlist module is required to generate 
> a file that instructs the linker on what functions/variable to 
> export/import.

This dependency on Mksymlist (which I agree is necessary) is a good 
example of how prerequisites can vary based on the system, and suggests 
that the "mini-language" dependency syntax I wrote about last week is 
getting pretty important.  Otherwise we have to have dynamic dependency 
lists depending on the platform, which I don't like.


> 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.
>

Okay, so people could override prelink_c() in their own subclasses?

> 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?

Yes, you're right.


> 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.

Great.  I think I'm going to push this release out before you have a 
chance to get to these issues, to let other people bang on it a little 
bit.  It's certainly way less broken now than it used to be, from the 
looks of things. =)

  -Ken