Don't use ppport.h when building dist/ modules in core

[haarg]

trafficstars

When building extensions in core, ppport.h should not be needed. Update IO and Unicode-Normalize to avoid it when built in core.

[jkeenan]

When building extensions in core, ppport.h should not be needed. Update IO and Unicode-Normalize to avoid it when built in core.

You will need a $VERSION boost in this p.r. I got these failures when testing:

porting/cmp_version.t                                              (Wstat: 0 Tests: 7 Failed: 2)
  Failed tests:  2, 4

[jkeenan]

When building extensions in core, ppport.h should not be needed. Update IO and Unicode-Normalize to avoid it when built in core.

You will need a $VERSION boost in this p.r. I got these failures when testing:

porting/cmp_version.t                                              (Wstat: 0 Tests: 7 Failed: 2)
  Failed tests:  2, 4

All tests now PASS.

[toddr]

Wouldn't this get rid of dog-fooding? what is the negative of using ppport.h in core builds? we already generate the file during builds.

[Leont]

I don't particularly like this, just generating ppport.h files feels like the simpler solution to me (it doesn't even have to be the real thing, it just has to exist)

[haarg]

All of the other modules in dist/ and many in cpan/ already exclude ppport.h when building in core. So if this is wrong, most XS dists in core are wrong.

[toddr]

All of the other modules in dist/ and many in cpan/ already exclude ppport.h when building in core. So if this is wrong, most XS dists in core are wrong.

ppport.h is generated in all of these distros automatically during build. See mkppport.lst

[haarg]

It's generated but not used. They all have checks for PERL_CORE, just like this adds.

[khwilliamson]

I'm wondering if we should have some uses of ppport.h in core so as to test that it works?

[Leont]

I'm wondering if we should have some uses of ppport.h in core so as to test that it works?

On blead nothing should be needing anything in ppport by definition, so I don't think we can do something meaningful there

[khwilliamson]

I think that what @Leont means is that there are a lot of version checks in ppport, so that things don't get compiled anyway. That may be true, but there have been times where there is a bug where blead fails to compile with ppport.h, and we don't discover it until a new release is cut. I think I'm coming down to keeping at least one instance of compiling D::P in blead.

[atoomic]

In blead there is no need to use ppport.h and as @haarg pointed out even if we generate it, we do not consume it. So I like the idea to avoid loading ppport.h in core.

I m concerned that we might mis-detect some potential issues with ppport.h

[tonycoz]

Wouldn't it be better to test Devel::PPPort (and other dist/ modules) against the various perl versions?

https://hub.docker.com/r/perldocker/perl-tester has a decent range of perl versions we could test against.

I don't think it would be trivial to do though :(

[Leont]

In blead there is no need to use ppport.h and as @haarg pointed out even if we generate it, we do not consume it. So I like the idea to avoid loading ppport.h in core.

To me, the simplifications that come with just always including it are far more valuable.

I m concerned that we might mis-detect some potential issues with ppport.h

What issues do you mean exactly? I don't think I understand.

[demerphq]

On Thu, 28 Jul 2022 at 13:57, Leon Timmermans @.***> wrote:

In blead there is no need to use ppport.h and as @haarg https://github.com/haarg pointed out even if we generate it, we do not consume it. So I like the idea to avoid loading ppport.h in core.

To me, the simplifications that come with just always including it are far more valuable.

+1

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[demerphq]

This seems to be stalled. Should we close it or merge it?

[Leont]

This seems to be stalled. Should we close it or merge it?

Either this or #20006 should be merged, I guess that's a PSC decision.

[tonycoz]

Wouldn't it be better to test Devel::PPPort (and other dist/ modules) against the various perl versions?

We now do this dog-fooding in CI, so there's now less need to test against ppport in core.

[toddr]

I'd prefer this be closed and #20006 be merged.

[demerphq]

I personally don't think we should need to go to the PSC to resolve the contention between this and #20006. This isn't a language design debate, its a build and test question that we should be able to resolve ourselves.

As far as I can tell, @demerphq (me), @Leont, and @toddr, and @khwilliamson are in favor of #20006.

On the vice-versa @haarg, @atoomic seem to favour #19888 (this PR).

@jkeenan and @tonycoz have commented, but haven't said specifically which they support (as far as I can tell).

Right now that means +2 vote for #20006. Does anyone want to change or clarify their position on this to achieve consensus? It really feels like we should not need to appeal to the "supreme court" of perl to decide a build matter like this.

Reminds me of a comment my dad once made, "the hardest decisions to make are the ones where there is minimal difference in the outcome of the decision made, if there was a larger difference it would be obvious which was the better choice"

[tonycoz]

I think #20006 is better.

[demerphq]

I am closing this ticket as unapplied. The ticket in #20006 has more votes by far.