logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: [Module::Build] Supporting either XS or PurePerl modules with a single : msg#00064

Subject: Re: [Module::Build] Supporting either XS or PurePerl modules with a single Build.PL
John Peacock wrote:
Except that violates the chosen mode I am operating in:

1) The XS module (being completely equivalent to Perl 5.10.0 is the default) is the default backend;

2) If the machine being installed on cannot support XS, then provide a pure Perl implementation (read slower) for those poor benighted souls without access to a C-compiler or a PPM repository.

I suppose I'll have to go this route to support all bases.

I don't see the real difference. All the PL files should do is create the .pm or .xs or .c files -- you can still default one way or another. The way I think of it, there are two possible distribution layouts, one for XS as the backend, the other for a PP backend. The .PL files job is only to make the layout resemble one or the other case.

For example, in Pod::WikiDoc, I include a precompiled Parse::RecDescent parser. The grammer sits in the __DATA__ section of the .PL file, and the .PL file just loads that up and passes it to PRD for compilation, which generates the .pm file.

What I'm suggesting (and I think Ken is) it to have a version.xs.PL file in the right place, with the XS in the __DATA__ section. If there's a C compiler available, slurp DATA and write it to the .xs file; if there's no C compiler available, then don't create it. Ditto for .c files.

For the .pm file, put both the stub version and PP version in __DATA__ with an appropriate separator line (e.g. '__SEPARATOR__' ) between the two. Slurp DATA and split on the separator. If the C compiler exists, write the stub content into the .pm. If not, write the PP content into the .pm.

That way, after .PL processing, the /lib directory looks right for either C compilation or pure Perl, and the rest of the Build cycle can just do the right thing on that basis. I think that's easier than trying to subclass/override the process_* sections.

David



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php


<Prev in Thread] Current Thread [Next in Thread>