Re: Why do we test a build using g++?

On Wed, 1 Jul 2026 10:35:00 +1000
Tony Cook <[email protected]> wrote:

> I suggested porting/cpphdrcheck, which checks the syntax of the
> headers, but it doesn't exercise the perl API beyond that.  This is a
> problem since the API has a large number of macros, which unlike
> inline functions are only syntax checked if you use them.

Ahyes; the macros. It's a shame C macros work that way, because yes the
compiler basically won't see them unless the code actually uses them.

> Perl itself probably exercises more of the API than any XS module
> does*, so that would be one reason to keep building as C++ in CI (some
> daily build reporters also run C++ builds, see
> https://perl.develop-help.com/#cc=%5C%2B%5C%2B ).
> 
> We could try adding a test C++ module in core to test against, but
> that's only going to exercise a tiny part of the API unless we put a
> ridiculous amount of effort into it.

Indeed; I agree it would be somewhat of a lot of effort to create such
a thing for this very minor niche use-case.

> Maybe we could do two builds of
> XS::APItest - one as C, another as C++, but I don't think that has the
> API coverage that perl itself does.

That sounds like at least it would give us much more coverage than the
cpphdrcheck test you previously mentioned, and not require much more
work. It might be a bit of time to work out how to set up that test,
but once it's there it doesn't require any more ongoing maintenance
than just the regular looking after APItest.xs.

> One alternative would be to have CI test a variety of C++ modules from
> CPAN, though that leaves CI vulnerable to failures due to
> network/infrastructure issues, and updates to those modules and their
> dependencies.  It may also be slow, since we're installing them and
> their dependencies from scratch each time.

Yeah; I'm not sure I like that one. Experience even with just some of
the TLS/SSL tests relying on external hosts suggests this would
probably give us far more false failures than we want to deal with.

> Another option is to just let CPAN testers test them and deal with the
> BBC reports as they come in.

Mmm, well this kinda hits at the root of the question. Why *do* we care
if the headers are fully compatible with C++ code? The only reason
really is to ensure that modules can be built in C++. But if there's
APIs or macros that nobody is using anyway, does it really matter?
Something about trees falling in forests, I think.

What I'm getting at here is asking: Are we trying too hard to build
testing for the *hypothetical* case that someone might want to use a
C++ compiler to build an XS module that uses some of our weirder more
obscure macros, at the cost of adding inconvenience for *actual real
present* uses of C99 features in real code people are actually writing
right now? Can we nudge that middle-ground a little away from the
hypothetical, and accept that maybe if we do happen to break a macro
for C++ users, that those users can always just report a bug and we can
fix it while adding a specific test for it?

-- 
Paul "LeoNerd" Evans

[email protected]
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS