module-build-general

[Module::Build] have_c_compiler uncovers Windoze bug

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

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.

Regards,
Randy.

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

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

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.
> 
> Regards,
> Randy.
> 

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.

Regards,
Randy.

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.

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

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

On Saturday, November 22, 2003, at 04:15  AM, Randy W. Sims wrote:
>
> 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.

Yes, but it should probably be a separate CPAN project with an 
interface well-defined enough that whoever wants to use it could use 
it.  Most likely its development directions would be largely be 
motivated by Module::Build's needs though, for at least the near future.

  -Ken

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

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

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 

Here is a tmp patch to fix have_c_compiler(). This is to fullfill what 
the prophet Ken spoke to Yves and all of module-authors saying:

"This is actually an unfortunate bug in version 0.21 on Win32.  Other 
previous versions have worked fine, and I believe this specific issue 
has already been fixed in CVS."

Actually, one major issue was already fixed in CVS. This is a fix for 
the only remaining major issue that I'm aware of (for MSWin32). This fix 
is ugly as sin. I probably should have wrote special overrides of 
have_c_compiler() for each of the compilers on MSWin32 that would 
manually invoke the compiler and linker (i.e. not use compile_c() & 
link_c()), but this solution should work for every platform/toolset for now.

There is, however, a small problem:

C:\devel\perl\bin\perl.exe Build.PL
Checking whether your kit is complete...
Looks good
Creating new 'Build' script for 'XSTest' version '0.01'
ok 1
ok 2
lib\XSTest.pm -> blib\lib\XSTest.pm
lib\XSTest.xs -> lib\XSTest.c
Generating script 'lib\XSTest.ccs'
cl -c @"lib\XSTest.ccs" -Fo"lib\XSTest.obj" "lib\XSTest.c"
XSTest.c
XSTest.xs(10) : warning C4129: 'X' : unrecognized character escape sequence
XSTest.xs(13) : warning C4129: 'X' : unrecognized character escape sequence
ExtUtils::Mkbootstrap::Mkbootstrap('lib\XSTest')
ExtUtils::Mksymlists::Mksymlists('lib\XSTest')

This is due to a problem in ExtUtils::ParseXS. EU::ParseXS generates 
lines like the following in the 'C' file:

#line 20 "lib\XSTest.c"

The backslash/Win32 dir separator in that string should be translated to 
a forward slash or double backslash. This is not a fatal error; it's 
just an annoying warning.

Randy.

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

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

On Saturday, November 29, 2003, at 04:56  AM, 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
>
> Here is a tmp patch to fix have_c_compiler(). This is to fullfill what 
> the prophet Ken spoke to Yves and all of module-authors saying:
>
> "This is actually an unfortunate bug in version 0.21 on Win32.  Other 
> previous versions have worked fine, and I believe this specific issue 
> has already been fixed in CVS."

Ah yes.  I wonder if all prophecy can be explained by wishful thinking. 
=)


[...]
>
> This is due to a problem in ExtUtils::ParseXS. EU::ParseXS generates 
> lines like the following in the 'C' file:
>
> #line 20 "lib\XSTest.c"
>
> The backslash/Win32 dir separator in that string should be translated 
> to a forward slash or double backslash. This is not a fatal error; 
> it's just an annoying warning.

Aha, I'll have to fix that too then.


I'm not sure I understand the patch, though.  It seems to just create a 
boot_compilet() C function, and make sure quotes are stripped from the 
object filename.  How does this fix the issue?

  -Ken

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

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

On 11/29/2003 11:31 AM, Ken Williams wrote:
> 
> I'm not sure I understand the patch, though.  It seems to just create a 
> boot_compilet() C function, and make sure quotes are stripped from the 
> object filename.  How does this fix the issue?
> 
>  -Ken

The problem is that the code in compile_c() and link_c(), on Windows 
specifically, but also M::B in general, is written to produce a dynamic 
perl module library. In Windows land an executable requires a different 
set of flags, etc to produce an executable file. So, instead of writting 
a lot of new scaffolding to compile an executable for the three 
different compilers on Windows, the patch basically adds enough to 
complete a minimal, skeletal, perl library. Without the boot_compilet() 
function, the linker would report an undefined reference to external 
symbol or something like.

I'm probably not explaining this well, but hopefully enough to make at 
least a little sense.

Randy.

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

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

On Saturday, November 29, 2003, at 10:48  AM, Randy W. Sims wrote:
>
> The problem is that the code in compile_c() and link_c(), on Windows 
> specifically, but also M::B in general, is written to produce a 
> dynamic perl module library. In Windows land an executable requires a 
> different set of flags, etc to produce an executable file. So, instead 
> of writting a lot of new scaffolding to compile an executable for the 
> three different compilers on Windows, the patch basically adds enough 
> to complete a minimal, skeletal, perl library. Without the 
> boot_compilet() function, the linker would report an undefined 
> reference to external symbol or something like.

Oh, I see.  I guess I could actually take out the main() function too 
then, right?  It's not used anywhere.

  -Ken

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

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

On 11/29/2003 11:58 AM, Ken Williams wrote:

> 
> On Saturday, November 29, 2003, at 10:48  AM, Randy W. Sims wrote:
> 
>>
>> The problem is that the code in compile_c() and link_c(), on Windows 
>> specifically, but also M::B in general, is written to produce a 
>> dynamic perl module library. In Windows land an executable requires a 
>> different set of flags, etc to produce an executable file. So, instead 
>> of writting a lot of new scaffolding to compile an executable for the 
>> three different compilers on Windows, the patch basically adds enough 
>> to complete a minimal, skeletal, perl library. Without the 
>> boot_compilet() function, the linker would report an undefined 
>> reference to external symbol or something like.
> 
> 
> Oh, I see.  I guess I could actually take out the main() function too 
> then, right?  It's not used anywhere.
> 
>  -Ken

Yeah, something like the following passes:

print $fh "boot_compilet() { return 1; }";