Re: podlators 4.04 released

[Russ Allbery]

"Craig A. Berry"  writes:
> On Sun, Jan 3, 2016 at 12:39 AM, Russ Allbery  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
> .

> 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 (ea...@eyrie.org)  

Re: podlators 4.04 released

[Russ Allbery]

"Craig A. Berry"  writes:

> You can't spell shebang without the "sh". The .PL files for the
> utilities are primarily to generate shebang emulation on non-Unix
> systems.  Yes, on unixy systems, what they do will reduce to just
> editing the shebang line, but on non-Unix systems they prepend the value
> of $Config{startperl}, which contains a native command to invoke perl
> and pass along its parameters, and then they add a suffix to the script
> name so the script will be recognized as a command by the command
> processor (.bat on Windows, .com on VMS).

Ah!  Thank you.  I hadn't understood that.

I'll re-add the .PL wrappers (with better documentation of why they're
required) directly in podlators and put out a new release.  Then hopefully
core can just use the same wrappers that come with the podlators CPAN
distribution.

-- 
Russ Allbery (ea...@eyrie.org)  

Re: podlators 4.04 released

[Craig A. Berry]

On Mon, Jan 4, 2016 at 1:51 PM, Russ Allbery  wrote:
> "Craig A. Berry"  writes:

>> 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.

You can't spell shebang without the "sh". The .PL files for the
utilities are primarily to generate shebang emulation on non-Unix
systems.  Yes, on unixy systems, what they do will reduce to just
editing the shebang line, but on non-Unix systems they prepend the
value of $Config{startperl}, which contains a native command to invoke
perl and pass along its parameters, and then they add a suffix to the
script name so the script will be recognized as a command by the
command processor (.bat on Windows, .com on VMS).

> 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.

I'm sure that's true if all you need to do is tweak the path to perl
on the shebang line.  But that's not all we need to do.  We could (and
used to) maintain the wrappers separately in core, but that seems like
extra work for folks upgrading core to new versions of podlators.