Thread: [Module::Build] Module-Build-0.21 on OS/2
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Ilya Z. <nos...@il...> - 2003-12-19 01:41:41
|
This patch is very incomplete... All it does is copying of cygwin architecture
file as os2 architecture file.
Given that Module::Build removed all the portability hooks of MakeMaker, it
will take a lot of effort to make Module::Build compile XS extensions on OS/2.
However, with the manpage_separator() of cygwin, at least the build of
pure-Perl extensions kinda-succeeds.
Yours,
Ilya
P.S. I did not try to fix other shortcomings of Module::Build, such as
incompatibility of the generated Makefile.PL with builds in
subdirectories. Hmm, I remember I saw two architecture-independent
problems; when I remember the other one, I will let you know...
--- ./MANIFEST-pre Wed Oct 15 17:39:20 2003
+++ ./MANIFEST Sun Dec 14 18:07:16 2003
@@ -22,6 +22,7 @@ lib/Module/Build/Platform/VOS.pm
lib/Module/Build/Platform/Windows.pm
lib/Module/Build/Platform/cygwin.pm
lib/Module/Build/Platform/darwin.pm
+lib/Module/Build/Platform/os2.pm
t/MANIFEST
t/Sample/Build.PL
t/Sample/MANIFEST
--- ./lib/Module/Build/Platform/os2.pm-pre Sun Dec 14 18:06:42 2003
+++ ./lib/Module/Build/Platform/os2.pm Sun Dec 14 18:06:16 2003
@@ -0,0 +1,46 @@
+package Module::Build::Platform::os2;
+
+use strict;
+use Module::Build::Platform::Unix;
+
+use vars qw(@ISA);
+@ISA = qw(Module::Build::Platform::Unix);
+
+sub link_c {
+ my ($self, $to, $file_base) = @_;
+ my ($cf, $p) = ($self->{config}, $self->{properties}); # For convenience
+ my $flags = $p->{extra_linker_flags};
+ local $p->{extra_linker_flags} = ['-L'.File::Spec->catdir($cf->{archlibexp}, 'CORE'),
+ '-lperl',
+ ref $flags ? @$flags : $self->split_like_shell($flags)];
+ return $self->SUPER::link_c($to, $file_base);
+}
+
+sub manpage_separator {
+ '.'
+}
+
+1;
+__END__
+
+
+=head1 NAME
+
+Module::Build::Platform::os2 - Builder class for OS/2 EMX platform
+
+=head1 DESCRIPTION
+
+This module provides some routines very specific to the OS/2 EMX
+platform.
+
+Please see the L<Module::Build> for the general docs.
+
+=head1 AUTHOR
+
+Initial stub by Ilya Zakharevich
+
+=head1 SEE ALSO
+
+perl(1), Module::Build(3), ExtUtils::MakeMaker(3)
+
+=cut
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 14:35:25
|
On 12/18/2003 8:41 PM, Ilya Zakharevich wrote: > This patch is very incomplete... All it does is copying of cygwin architecture > file as os2 architecture file. > > Given that Module::Build removed all the portability hooks of MakeMaker, it > will take a lot of effort to make Module::Build compile XS extensions on OS/2. > However, with the manpage_separator() of cygwin, at least the build of > pure-Perl extensions kinda-succeeds. If the link_c() sub is not correct, it would be best to remove it from the patch. Doesn't OS/2 perl use static linking for perl modules? Can you provide a dump of your Config.pm to help porting? Thanks, Randy. |
|
From: Ilya Z. <nos...@il...> - 2003-12-21 08:43:46
Attachments:
Config.pm
|
On Sat, Dec 20, 2003 at 09:35:10AM -0500, Randy W. Sims wrote: > If the link_c() sub is not correct, it would be best to remove it from > the patch. Doesn't OS/2 perl use static linking for perl modules? On OS/2 Perl is built in many flavors. The main one uses DynaLoading. One of the others is statically built. With statically build one, the supplied link_c() may be working (have no time to test this). > Can you provide a dump of your Config.pm to help porting? All the flavors use the same Config.pm (they switch the values basing on configuration variables/functions available via OS2:: namespace). So be prepared that the same Config.pm may provide radically different answers. ;-) Yours, Ilya |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 14:44:05
|
On 12/18/2003 8:41 PM, Ilya Zakharevich wrote: > This patch is very incomplete... All it does is copying of cygwin architecture > file as os2 architecture file. > > Given that Module::Build removed all the portability hooks of MakeMaker, it > will take a lot of effort to make Module::Build compile XS extensions on OS/2. > However, with the manpage_separator() of cygwin, at least the build of > pure-Perl extensions kinda-succeeds. Ken, until compiling does work you might want to put in a stub for have_c_compiler() to return false to avoid errors. Regards, Randy. |
|
From: Ken W. <ke...@ma...> - 2003-12-20 16:11:44
|
On Saturday, December 20, 2003, at 08:43 AM, Randy W. Sims wrote: > On 12/18/2003 8:41 PM, Ilya Zakharevich wrote: > >> This patch is very incomplete... All it does is copying of cygwin >> architecture >> file as os2 architecture file. >> Given that Module::Build removed all the portability hooks of >> MakeMaker, it >> will take a lot of effort to make Module::Build compile XS extensions >> on OS/2. >> However, with the manpage_separator() of cygwin, at least the build of >> pure-Perl extensions kinda-succeeds. > > Ken, until compiling does work you might want to put in a stub for > have_c_compiler() to return false to avoid errors. Done. It would be great if we could actually get this working in ExtUtils::CBuilder, and then switch over so that M::B uses it. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 16:40:33
|
On 12/20/2003 11:11 AM, Ken Williams wrote: > > On Saturday, December 20, 2003, at 08:43 AM, Randy W. Sims wrote: > >> On 12/18/2003 8:41 PM, Ilya Zakharevich wrote: >> >>> This patch is very incomplete... All it does is copying of cygwin >>> architecture >>> file as os2 architecture file. >>> Given that Module::Build removed all the portability hooks of >>> MakeMaker, it >>> will take a lot of effort to make Module::Build compile XS extensions >>> on OS/2. >>> However, with the manpage_separator() of cygwin, at least the build of >>> pure-Perl extensions kinda-succeeds. >> >> >> Ken, until compiling does work you might want to put in a stub for >> have_c_compiler() to return false to avoid errors. > > > Done. > > It would be great if we could actually get this working in > ExtUtils::CBuilder, and then switch over so that M::B uses it. > > -Ken > I'm actually quite eager to dig into CBuilder, but it seems like everytime I get ready to something comes up. Fixing the Windows code should be trivial. I've got a lot of the scaffolding already written for doing static builds; I don't think it'll take much to complete it. The code for building executables should also be trivial. I just gotta find some time... Randy. |
|
From: Ken W. <ke...@ma...> - 2003-12-20 20:17:36
|
On Saturday, December 20, 2003, at 10:40 AM, Randy W. Sims wrote: > > I'm actually quite eager to dig into CBuilder, but it seems like > everytime I get ready to something comes up. Fixing the Windows code > should be trivial. Ooh, I was hoping you'd say that. =) It probably wouldn't be trivial for me, because I'd have to start understanding how it works. In fact, if you're interested, I'd be happy to hand the CBuilder code over to you as official maintainer/owner. Just let me know. > I've got a lot of the scaffolding already written for doing static > builds; I don't think it'll take much to complete it. The code for > building executables should also be trivial. I just gotta find some > time... Yeah, it's only recently that I've understood that doing static builds is necessary. I think that your synopsis a couple weeks ago of the various issues related to CBuilder was good. Some of them (like building executables, for example) can easily wait until later versions, though - for now we can just focus on doing the stuff that tools like M::B will need to build XS modules. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-21 09:08:27
|
On 12/20/2003 3:17 PM, Ken Williams wrote: > > On Saturday, December 20, 2003, at 10:40 AM, Randy W. Sims wrote: > >> >> I'm actually quite eager to dig into CBuilder, but it seems like >> everytime I get ready to something comes up. Fixing the Windows code >> should be trivial. > > Ooh, I was hoping you'd say that. =) It probably wouldn't be trivial > for me, because I'd have to start understanding how it works. > > In fact, if you're interested, I'd be happy to hand the CBuilder code > over to you as official maintainer/owner. Just let me know. It's so much more fun when you're not maintainer; You still get to write code. You get to annoy the maintainer with patches, bug reports, feature requests, etc. Any you get none of the aforesaid annoyances. ;-) Actually, I'd be happy to help out in any way I can, whether as maintainer, co-maintainer, or as an annoyance. >> I've got a lot of the scaffolding already written for doing static >> builds; I don't think it'll take much to complete it. The code for >> building executables should also be trivial. I just gotta find some >> time... > > > Yeah, it's only recently that I've understood that doing static builds > is necessary. > > I think that your synopsis a couple weeks ago of the various issues > related to CBuilder was good. Some of them (like building executables, > for example) can easily wait until later versions, though - for now we > can just focus on doing the stuff that tools like M::B will need to > build XS modules. I completely agree. For the foreseeable future all development on CBuilder should be driven by the requirements of M::B. The top priority being to get CBuilder to do what is currently handled internally by M::B. Then it can be extended to handle static builds, more platforms, etc. as needed. Regards, Randy. |
Thanks for helping keep SourceForge clean.
X