Re: [Module::Build] have_c_compiler uncovers Windoze bug

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

On 11/2/2003 1:55 PM, Randy W. Sims wrote:

> On 10/30/2003 9:36 PM, Randy W. Sims wrote:
> 
>> Hi Ken,
>>
>> Version 1.220 of M::B::Base.pm uncovered a bug. On Windows, an 
>> executable requires different options to the linker than a dynamic 
>> library. Currently link_c() is configured strictly to produce 
>> libraries. A quick and perhaps naive fix is to introduce an optional 
>> paramater to link_c() to indicate the desired type of the output file. 
>> But, I want to wait as I've also been looking into porting to AT&T's 
>> U/WIN Unix on Windows environment 
>> <http://www.research.att.com/sw/tools/uwin/> (like Cygwin, and it is 
>> going to require implementing static linking (see "Static Linking of a 
>> new Perl Binary" in the MM docs). This might also involve changes to 
>> link_c(), but I'm not sure yet. I'll post more when I learn more and 
>> before I start patching. But it may be this weekend as I'm going to 
>> set up a new computer thats been collecting dust; I'm going to setup 
>> Debain linux, one of the BSDs, Windows 2000, & Windows 98, multiboot 
>> so that I'll have a good testing system.
>>
> 
> I didn't get to work on this as much as I had hoped, but I did get some 
> of the scaffolding in place for the static linking. I've attached it in 
> case you want to look it over to see where it's going. It may be toward 
> the middle of the week before I can get back to it.
> 

This (if not obvious by now) did not go as well as I hoped. The current 
architecture for compiling and linking will not currently support this 
addition without a lot of work, and before doing that I think it better 
to discuss options and see how you want to proceed.

We talked before about two sub-projects we both agreed would be good for 
Module::Build: 1) a compiler framework, and 2) a plugin framework. My 
current thinking is that both of these are part of the solution to this 
problem.

I think that the compiler framework should provide a low level interface 
for invoking the compiler/linker/etc in a unified manner. In other words 
it would define a standard set of options which it would then translate 
to the proper options to the underlying tool. This low level interface 
would rarely be used except by Module::Build itself.

The plugin framework would provide an architecture for creating 
"actions" and "builders" (helpers to construct actions). I think 
"builders" are the missing key to providing an easy, expandable, means 
of creating libraries. Thus the primary interface is one that focuses on 
what instead of how:

my $lib_action = Module::Build::Action::Builder::new_library(
   link_type => 'static',
   name      => 'XSTest',
   sources   => [ 'XSTest/XSTest.xs' ],
   use_perl  => 1, # indicates should use flags/defines from Config.pm
   ...
);

Module::Build::Action::find_by_name('code')->add_dependency($lib_action);

...

my $bin_action = Module::Build::Action::Builder::new_executable(
   name     => 'compilet',
   sources  => [ 'compilet.c' ],
   use_perl => 0,
   ...
);

my $cc_test = Module::Build::Action::Builder::new(
   name => 'cc_test',
   code => sub (
     $bin_action->exec;
     return -e $bin_action->outfile;
   )
);

sub have_c_compiler { return $cc_test->result }


Well, something like that. Will this work? Opinions? Suggestions?

I may try to experiment some more with the plugin aspect since it would 
seem to need to come first. I'll post a patch when I can, if your 
interested.

Regards
Randy.