Add Internals::DEBUGGING to test perl was built with DEBUGGING defined

[tonycoz]

This is one possible implementation, others might be:

• builtin::is_debug_build (or some other name)
• ${^DEBUGGING}

both of which use a more public namespace, but Internals::DEBUGGING seemed the least disruptive for now.

This was inspired by #24762, but it's an issue that has come up before - someone writes a test conditional on whether perl was built with -DDEBUGGING or its platform specific invocation (MSWin32, VMS), and that conditional is incomplete or incorrect.

The idea here is to add an authoritative and always correct way to check whether perl itself was builtin with DEBUGGING enabled - by checking whether universal.c has the DEBUGGING macro defined. This should also work where a debugging build perl binary is parallel installed with a non-debugging build, as with debugperl binary installed by the perl-debug package on Debian.

We could suggest parsing Internals::V, and the test code for this change does that, but Internals::V is subject to any changes needed for Config::_V() so it's fragile.

The main type of feedback in addition to the implementation that I'm looking for, is should this be public? If public, what shape should that public-ness take - a builtin:: name? a ^ variable? Or document Internals::DEBUGGING?

I'm not fond of putting this into builtin:: - those names are intended to become builtins at some point, and this doesn't seem suitable for that.

---

• This set of changes may require a perldelta entry, depending on whether we add a public interface.

[jkeenan]

Given that right now I can type perldoc Internals and read about various functions, it seems to me that Internals::<anything> is just as public now as builtin:: or `${^DEBUGGING}.

OTOH, farther down perldoc Internals says this:

BEWARE: This module is DANGEROUS!

DO NOT attempt to unlock Perl's built-in variables!

DO NOT manipulate reference counts unless you know exactly what you're
doing!

ANYTHING might happen! Hell might break loose! ":-)"

YOU HAVE BEEN WARNED!

... which sounds like, "We're showing you the rope with which you can hang yourself, but if you use it the Secretary will disavow all knowledge of your activity."

I know that as a person working on the tests found in the core distribution, I need a definitive way to determine whether a given executable is a debugging perl or not, and I need that to work with miniperl and inside programs where the tests are run via t/test.pl. But do non-core Perl users need it?

[xenu]

Why not put this in a %Config key? e.g. $Config{debugging}

[xenu]

Nevermind, Debian's debugperl wouldn't be compatible with it. What an odd setup to support, BTW.

[haarg]

It feels like this would make more sense as a %Config entry. Config_heavy.pl already has code to update %Config entries based on Internals::V.

[richardleach]

I like the correctness of the implementation; not sure about if/how to expose it publicly.

If it is useful to people, then might we end up exposing more build details in the future? If so, not sure we'll want to ^ variables for each of them.

If it does go into Internals (or builtin), is this a good time to consider second level namespaces?

[tonycoz]

It feels like this would make more sense as a %Config entry. Config_heavy.pl already has code to update %Config entries based on Internals::V.

Config seems like a good place to put it, assuming the value depends on the perl binary rather than the canned config.

Rather than a %Config entry (I tend to think of these as mirroring config.sh), how about as a constant sub in Config::?

and I need that to work with miniperl

Do you need it before Config.pm is built? Since that isn't necessarily available for minitest for example.

and inside programs where the tests are run via t/test.pl.

I'm not sure if you meant this to be "where tests are not run via t/test.pl" in addition to use in t/test.pl tests.

But do non-core Perl users need it?

I think it could be useful for XS authors

[jkeenan]

The following test files are all run during make minitest -- i.e., they
are not skipped -- and they all have code that asks if they're being run by
a debugging build of perl.

• t/op/aassign.t

272 SKIP: {
273     use Config;
274     # debugging builds will detect this failure and panic
275     skip "DEBUGGING build" if $::Config{ccflags} =~ /(?<!\S)-DDEBUGGING(?!\S)/
276                               or $^O eq 'VMS' && $::Config{usedebugging_perl} eq 'Y';

• t/op/glob.t

  9 use Config;
 10 my $is_debugging_build = $Config{config_args} =~ /\bDDEBUGGING\b(*nla:=none)/;
...
154 SKIP: {
155     skip "Debugging builds on Linux and Cygwin still problematic: GH 16869", 1
156         if (
157             ($Config{osname} eq 'linux' or $Config{osname} eq 'cygwin') and
158             $is_debugging_build
159         );

• t/op/signatures.t

1611 SKIP: {
1612     use Config;
1613     skip "DEBUGGING build required", 1
1614         unless $Config{ccflags} =~ /(?<!\S)-DDEBUGGING(?!\S)/
1615             || $^O eq "VMS" && $Config{usedebugging_perl} eq "Y";
1616 

• t/run/runenv_hashseed.t

250         SKIP: {
251             # skip these tests if we are not running in a DEBUGGING perl.
252             skip "$descr not testing rand bits, not a DEBUGGING perl", 3
253                 if @$rand_bits1 + @$rand_bits2 == 0;
254 

• t/run/todo.t

106 my $is_debugging_build = $Config{config_args} =~ /\bDDEBUGGING\b(*nla:=none)/;
...
296 TODO: {
297     todo_skip "Test needs -DDEBUGGING", 1 unless $is_debugging_build;
298     local $::TODO = 'GH 16522';
...
306 TODO: {
307     todo_skip "Test needs -DDEBUGGING", 1 unless $is_debugging_build;
308     local $::TODO = 'GH 16863';
...
322 TODO: {
323     todo_skip "Test needs -DDEBUGGING on Linux and on Cygwin, no miniperl", 1
324         unless (
325             $is_debugging_build and
326             ($Config{osname} eq 'linux' or $Config{osname} eq 'cygwin') and
327             ! is_miniperl()
328         ); 
329     local $::TODO = 'GH 16869';
...
337 TODO: {
338     todo_skip "Test needs -DDEBUGGING", 1 unless $is_debugging_build;
339     local $::TODO = 'GH 16876';

There may be others. I didn't look at tests under dist/, ext/ or lib/.

[tonycoz]

The following test files are all run during make minitest -- i.e., they
are not skipped -- and they all have code that asks if they're being run by
a debugging build of perl.

The thing is: minitest isn't meant to require that Config.pm ls loadable, minitest_prep:

minitest_prep: $(MINIPERL_EXE)
        -@test -f lib/Config.pm || $(MAKE) lib/Config.pm $(unidatafiles)
        @echo " "
        @echo "You may see some irrelevant test failures if you have been unable"
        @echo "to build lib/Config.pm, or the Unicode data files."
        @echo " "
        cd t && (rm -f $(PERL_EXE); $(LNS) ../$(MINIPERL_EXE) $(PERL_EXE))

will try to build Config.pm, but even if that fails it will try to run the tests.

So ideally tests in MINITEST_TESTS:

MINITEST_TESTS = base/*.t comp/*.t cmd/*.t run/*.t io/*.t re/*.t opbasic/*.t op/*.t uni/*.t perf/*.t

should avoid a hard requirement on Config.pm.

Though we don't follow that well except for base, comp and cmd.

From what you've listed it looks like we don't really need it before Config.pm.