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

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

On Tuesday, February 25, 2003, at 06:53  PM, Randy W. Sims wrote:

> On 2/24/2003 12:56 PM, Ken Williams wrote:
>> 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. =)
>
> I've been thinking very seriously about writing those modules. My 
> problem is the more I think about it the more ambitious the design 
> becomes. I'm more inclined at the moment to design them as a framework 
> not limited to 'C' and 'XS', so that Inline::* modules could make use 
> of the framework if desired. Instead of ExtUtils::C::Linker, there 
> would be something like:
>
> my $cc = new ExtUtils::Compiler(
>   LANG  => 'C',
>   FLAGS => ...
> );
>
> $cc->compile( source => 'source.c', output => 'source.o' );
>
> In other words, it would operate like 'gcc' does, where it is a 
> front-end driver for any number of different compilers.

Eek, dangerous road! ;-)  When I've entertained writing this, it's only 
by limiting the scope of the design that I can convince myself it's 
worth doing, because I might have a reasonable chance of ever 
finishing. =)

That said, probably all you'd need to do is define the *interfaces*, 
implement the stuff we need for C compilation, and let other people 
provide the code to support various languages.

By the way, one other author (Mitchell Charity) told me a while ago 
about some work he was doing with ExtUtils::ParseXS in which he was 
generating the C code in memory, then using TinyCC's libtcc to do an 
all-in-memory compile and link, and claiming something like three 
orders of magnitude difference in speed (faster, not slower ;-).  I 
probably wouldn't even understand the details if I knew them, but my 
point is that tools like this could be really useful, because there are 
people out there that can do cool stuff with them.  So if you think you 
could get something working, I'm completely supportive. =)

> I agree, in fact the first implementation actually used an aggregate 
> relationship instead of inheritance. In fact there is still a relic of 
> that design in there. In the constructor, you see:
>
> my $cc_driver = "Module::Build::Platform::Windows::$cf->{ccname}";
> unshift @ISA, $cc_driver;
>
> the next line used the be something like
> $self->{config}{cc_driver} = eval "new $cc_driver";

By the way, that can just be

  $self->{config}{cc_driver} = $cc_driver->new();


> The problem was that it would have taken more code to implement mostly 
> duplicating code already in M::B or storing a backref to the caller 
> (which I generally prefer to avoid), and that really didn't seem to 
> make sense within the context of M::B.

Okay.  One way to avoid storing backreferences (for too long) is to use 
weak references, but we probably don't want to get into that for M::B 
either.

>
> In my notes, I put down the names of two of the files: 'Sample.pm' & 
> 'MANIFEST'. There may be others; I admit that I mostly ignored the 
> errors at the time because I was focusing on the compiling/linking 
> tests and I didn't want to get sidetracked. I'll take a closer look at 
> this.

Does anything change if you add an explicit close() in 
version_from_file() ?  I think that's the only place Sample.pm would be 
opened.

For the MANIFEST, all that code is buried in ExtUtils::Manifest, so 
it'll be harder to fix, probably.


> This is something else I wanted to revisit. If I'm not mistaken this 
> may actually be a Perl bug that was in 5.6.1, but has since been 
> fixed. At least I think I remember some problem being fixed in the 
> system() call.

Oh yuck. =(  Well, let me know if you find anything, but I hope you 
don't!


> I guess it could be argued either way: subclassing or passing 
> arguments to M::B's constructor. If subclassing, users need to know 
> that on some platforms that there is a prelink operation, and that it 
> generally involves a call ExtUtils::Mksymlists. They will have to 
> reference that documentation to see what arguments they need to pass. 
> If it were just parameters passed to M::B's constructor, It would 
> arguably simplify the interface and documentation, at least from the 
> users perspective. However, design-wise it shifts responsiblities in 
> the wrong direction; the reason there is a seperate module for 
> Mksymlists in the first place is to move that responsiblity out of the 
> package used for building modules.

Indeed.

> The way I wrote the prelink_c() routine should allow you easily go in 
> either direction as you prefer.

Okay, thanks.

  -Ken