[Module-build-general] Re: redirecting system() to a file, or ways to avoid it

[Michael G S. <sc...@po...>]

SF.net hates me, so I'll just post straight to you.


On Wed, Nov 27, 2002 at 12:13:23AM +1100, Ken Williams wrote:
> In Module::Build, very little is done by the external system, but some
> things still are.  One little thorn in its side is ExtUtils::xsubpp -
> which, despite living in @INC and having two colons in its name, is a
> script, not a module.  In order to parse .xs files, this script 
> needs to
> be called and its output redirected to a file.

I hereby disavow all responsiblity for xsubpp, Amen.

You might want to look at the ExtUtils::MM_Unix->tool_xsubpp 
method to see
how MakeMaker locates xsubpp and the typemap file.


> That's not usually a very hard task, but I've decided to use the
> multi-arg form of system() whenever possible, so that I don't have to
> handle argument quoting issues on all the platforms of the world.  But
> the multi-arg form of system() doesn't let me do output 
> redirects (which
> probably weren't portable across platforms anyway with single-arg
> system()).

In general `someprogram some args > some_file` is plenty 
portable, even on
VMS.  And that should be all you need.
`$^X path/to/xsubpp -some -args foo.xs > some_tmp_file`

What isn't portable is any piping or redirecting STDERR.

If you look at the new code in ExtUtils::MM_Unix->find_perl() 
you'll see we
supress STDERR by temporarily closing it.
http://makemaker.org/src/ExtUtils-MakeMaker-snap/lib/ExtUtils/MM_Unix.pm

     # To avoid using the unportable 2>&1 to supress STDERR,
     # we close it before running the command.
     close STDERR if $stderr_duped;
     $val = `"$abs" -e "require $ver; print qq{VER_OK\n}"`;
     open STDERR, '>&STDERR_COPY' if $stderr_duped;

Closing STDERR outright seems portable.  Tying STDERR and/or STDOUT to a
file may be unreliable in certain versions of Perl.

> So I'm trying to think of the best alternative.  Choices include:
>
>  1) Wrap all of the xsubpp code into a subroutine, set @ARGV, open
> STDOUT to a file, and call the subroutine.
>
>  2) Same as 1), but just do() the xsubpp file instead of making it a
> subroutine.

#1 would work.  Something like:

     sub xsubpp {
         my($self, $file) = @_;
	local @ARGV = ($file);
	
	open(SAVE_STDOUT, '>&STDOUT');
	tie *STDOUT, to memory;
	
	do ExtUtils::xsubpp;
	
	open(STDOUT, '>&SAVE_STDOUT');
	
	return $whatever_you_captured;
     }

Normally you could get away with just "select(*TIED)" but xsubpp 
has hard
coded "print STDOUT" it and it too plays with "select(*STDOUT)".

Tying STDOUT is sometimes a little twitchy.


>  3) Write some function to convert multi-arg system() calls to
> safely-quoted single-arg system() calls, in a cross-platform way, with
> cross-platform support for output redirection.

See ExtUtils::MM_Any->oneliner in the snapshots.  But you should be safe
without all that work.


>  4) Go back in time and re-implement ExtUtils::xsubpp as a bare-bones
> wrapper around an ExtUtils::ParseXS module.  Module::Build can 
> just call
> functions in ExtUtils::ParseXS, then.
>
>  5) Don't go back in time, but create an ExtUtils::ParseXS module
> nonetheless, which *future* versions of xsubpp could use as guts.
> Create a Module::Build dependency on ExtUtils::ParseXS and don't call
> xsubpp.

I'd like that.


>  6) Borg all the xsubpp code into Module::Build where I can control it.

The stuff in xsubpp is supposed to be very version specific, 
that's why we
don't ship it with the CPAN version of ExtUtils::MakeMaker.


> Even though 1) and 2) are pretty ugly, I'm leaning toward doing one of
> them, if they'd work.  3) looks non-fun, and the further away I can get
> Module::Build and system() from each other, the better.  4) and 
> 5) would
> be a lot of work, but probably the best from an architectural point of
> view.  4) would be really cool, actually.  Note that 5) would 
> create the
> first non-5.6-core dependency in Module::Build, though.  And 6) seems
> like a bad idea.
>
> There's also:
>
>  7) Just write it as a single-arg, ad hoc system() call, don't worry
> about cross-platform issues, make those MacOS bastards live without XS
> compilation a little while longer, and only fix the quoting 
> when someone
> tells me it's broken on VMS and Amiga, and Win95.

I think it'll work on MacPerl since any XS compiling requires 
the MPW shell.
MacPerl might also just emulate `perl ...`.


--

Michael G. Schwern   <sc...@po...>    
http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee 
Is Job One
michael schwern is