"Craig A. Berry" <[email protected]> writes: > On Sun, Jan 3, 2016 at 12:39 AM, Russ Allbery <[email protected]> wrote:
>> I'm pleased to announce release 4.04 of podlators. This fixes some >> test portability and merges changes made as part of the import into >> blead. >> Please let me know of any problems or feature requests not already listed >> in the TODO file. > One of the recent integrations did away with > cpan/podlators/scripts/pod2man.PL and > cpan/podlators/scripts/pod2text.PL and added pre-built versions in > cpan/podlators/bin. Core integration then put copies of the .PL files > in utils/ but did not change the location in utils.lst. This makes it > dodgy whether they will get built and installed correctly on non-Unix > systems and partially undoes the intent of > <http://perl5.git.perl.org/perl.git/commit/bab7aada2e9c0074c39ee39ffeb3b8e6c550b204>. > I think core integration would be easier if we just stuck with .PL > files under cpan/podlators/scripts. That way they'll get built > correctly for the target platform and there should be less > customization to bring a new version into core. Is there any reason > to prefer distributing Unix-specific scripts under bin/? My understanding was that it's no longer necessary to use .PL scripts and all of their machinery just to replace the #! line (and that's all podlators needs done), and that ExtUtils::MakeMaker now knows how to replace the #! lines properly without requiring that be written out manually in every package. Is that not the case? If not, I can restore the previous wrappers, but I was really hoping that was a thing of the past. ExtUtils::MakeMaker's documentation for EXE_FILES says: If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
