"Craig A. Berry" <craig.a.berry@gmail.com> writes: > On Sun, Jan 3, 2016 at 12:39 AM, Russ Allbery <eagle@eyrie.org> 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 (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>Thread Previous | Thread Next