develooper Front page | perl.par | Postings from September 2008

[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem

Thread Previous | Thread Next
From:
Steffen Mueller via RT
Date:
September 5, 2008 10:16
Subject:
[rt.cpan.org #38067] Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem
Message ID:
rt-3.6.HEAD-12451-1220625476-1898.38067-15-0@rt.cpan.org
Fri Sep 05 10:37:57 2008: Request 38067 was acted upon.
Transaction: Correspondence added by SMUELLER
       Queue: PAR-Packer
     Subject: Can't use XML::SAX in a PAR::Packer standalone due to ParserDetails.ini problem
   Broken in: (no value)
    Severity: (no value)
       Owner: Nobody
  Requestors: ndo@unikservice.com
      Status: new
 Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38067 >


I don't have a general fix for this, but I'd like to note that this is
*not* the case for "normal" pp-generated executables. If you include the
INI file in the package, it'll be normally extracted and found.

Only if you use XML::SAX directly from a .par file or from an executable
which was built with the --clean option, it won't extract the INI.

Personally, I think it's a pretty bad idea to put any configration files
in Perl's module path hierarchy, but I may be biased.

One possible (but XML-SAX-side) fix would be to add a few lines to the
code that searches for the INI file:

If the search fails, check whether PAR is loaded and if so, have it try
to search in any loaded .par files for the INI file. Untested:

my $fh = gensym();
if (!open($fh, File::Spec->catfile($dir, "SAX", PARSER_DETAILS))) {

my $path = "lib/XML/SAX/".PARSER_DETAILS();

XML::SAX->do_warn("could not find " . PARSER_DETAILS . " in
$dir/SAX\n");
return $class;
}

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About