MM.pm: treat undefined mtimes as 0 to avoid warnings

[nabbi]

Insert // 0 for mtime comparisons so missing pod or Makefile are treated as 0. Preserves original skip behavior while preventing "uninitialized value" warnings in numeric comparisons.

This suppresses 3077 uninitialized occurrences when building ZoneMinder on Gentoo using cmake 4.1.2 perl 5.42.0

Use of uninitialized value in numeric gt (>) at /usr/lib64/perl5/5.42/ExtUtils/Command/MM.pm line 147.

• This set of changes does not require a perldelta entry.

[Leont]

It seems to me like there's some context missing here? What is different about ZoneMinder that this happens here? I haven't seen this anywhere else.

AFAICT, mtime would only return 0 if a file doesn't exist(or if one doesn't have the permissions needed to stat (but that seems less likely). I can vaguely imagine this sort of change for Makefile.PL if it's used out-of-context, but for $pod something would be gravely wrong because that's the input file.

[nabbi]

my debug block:

        my ($man_mtime, $pod_mtime, $makefile_mtime) =
            (mtime($man), mtime($pod), mtime("Makefile"));

        warn sprintf(
            "DEBUG: man=%s mtime=%s, pod=%s mtime=%s, Makefile mtime=%s\n",
            $man,
            defined $man_mtime      ? $man_mtime      : 'undef',
            $pod,
            defined $pod_mtime      ? $pod_mtime      : 'undef',
            defined $makefile_mtime ? $makefile_mtime : 'undef',
        );

        warn "DEBUG: pod file '$pod' does not exist\n"
            if !-e $pod;

I get a mix of no mtime for pod and always no mtime for Makefile.

The "pod file does not exist" never logs.

DEBUG: man=blib/man3/WSNotification::Types::TopicExpressionType.3pm mtime=1765495870, pod=lib/WSNotification/Types/TopicExpressionType.pm mtime=undef, Makefile mtime=undef

DEBUG: man=blib/man3/WSNotification::Types::TopicExpressionType.3pm mtime=1766861352.55937, pod=lib/WSNotification/Types/TopicExpressionType.pm mtime=1765495870, Makefile mtime=undef


DEBUG: man=blib/man3/WSNotification::Types::UnrecognizedPolicyRequestFaultType.3pm mtime=1765495870, pod=lib/WSNotification/Types/UnrecognizedPolicyRequestFaultType.pm mtime=undef, Makefile mtime=undef

DEBUG: man=blib/man3/WSNotification::Types::UnrecognizedPolicyRequestFaultType.3pm mtime=1766861352.5827, pod=lib/WSNotification/Types/UnrecognizedPolicyRequestFaultType.pm mtime=1765495870, Makefile mtime=undef

I don't doubt there's some combination of gentoo's build sandbox and zoneminders code triggering this behavior.

[jkeenan]

my debug block:

        my ($man_mtime, $pod_mtime, $makefile_mtime) =
            (mtime($man), mtime($pod), mtime("Makefile"));

        warn sprintf(
            "DEBUG: man=%s mtime=%s, pod=%s mtime=%s, Makefile mtime=%s\n",
            $man,
            defined $man_mtime      ? $man_mtime      : 'undef',
            $pod,
            defined $pod_mtime      ? $pod_mtime      : 'undef',
            defined $makefile_mtime ? $makefile_mtime : 'undef',
        );

        warn "DEBUG: pod file '$pod' does not exist\n"
            if !-e $pod;

I get a mix of no mtime for pod and always no mtime for Makefile.

The "pod file does not exist" never logs.

DEBUG: man=blib/man3/WSNotification::Types::TopicExpressionType.3pm mtime=1765495870, pod=lib/WSNotification/Types/TopicExpressionType.pm mtime=undef, Makefile mtime=undef

DEBUG: man=blib/man3/WSNotification::Types::TopicExpressionType.3pm mtime=1766861352.55937, pod=lib/WSNotification/Types/TopicExpressionType.pm mtime=1765495870, Makefile mtime=undef


DEBUG: man=blib/man3/WSNotification::Types::UnrecognizedPolicyRequestFaultType.3pm mtime=1765495870, pod=lib/WSNotification/Types/UnrecognizedPolicyRequestFaultType.pm mtime=undef, Makefile mtime=undef

DEBUG: man=blib/man3/WSNotification::Types::UnrecognizedPolicyRequestFaultType.3pm mtime=1766861352.5827, pod=lib/WSNotification/Types/UnrecognizedPolicyRequestFaultType.pm mtime=1765495870, Makefile mtime=undef

I don't doubt there's some combination of gentoo's build sandbox and zoneminders code triggering this behavior.

I just cloned zoneminder from GitHub. I searched for several strings from your debug block therein:

$ ack '(\$man_mtime|warn\s+sprintf|\$DEBUG)' .
$ 

... but came up with nothing. That suggests the problem may be in your build sandbox.

[nabbi]

... but came up with nothing. That suggests the problem may be in your build sandbox.

Sorry? I added that block into MM.pm to see what it was processing, just above the original line 147 outputs in the original post

[nabbi]

The uninitialized are being thrown during portage install phase.

ebuild zoneminder-1.37.74.ebuild install

MM.pm is called prior during the compile phase and logs no mtime for pod files, but doesn't throw uninitialized until later.

>>> Install www-misc/zoneminder-1.37.74 into /var/tmp/portage/www-misc/zoneminder-1.37.74/image
 * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/www-misc/zoneminder-1.37.74/work/zoneminder-1.37.74"
 * Build directory  (BUILD_DIR):     "/var/tmp/portage/www-misc/zoneminder-1.37.74/work/zoneminder-1.37.74_build"
ninja -v -l8 -j22 install
[1/4] cd /var/tmp/portage/www-misc/zoneminder-1.37.74/work/zoneminder-1.37.74_build/onvif/modules && perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1 FIRST_MAKEFILE=MakefilePerl DESTDIR="/var/tmp/portage/www-misc/zoneminder-1.37.74/work/zoneminder-1.37.7
4_build/onvif/modules/output" && make -f MakefilePerl pure_install
Generating a Unix-style MakefilePerl
Writing MakefilePerl for ONVIF
Writing MYMETA.yml and MYMETA.json
Skip blib/lib/ONVIF/Serializer/SOAP11.pm (unchanged)
Skip blib/lib/WSDiscovery/TransportUDP.pm (unchanged)
Skip blib/lib/ONVIF/Deserializer/XSD.pm (unchanged)
Skip blib/lib/ONVIF/Serializer/SOAP12.pm (unchanged)
Skip blib/lib/ONVIF/Serializer/Base.pm (unchanged)
Skip blib/lib/ONVIF/Client.pm (unchanged)
Skip blib/lib/ONVIF/Deserializer/MessageParser.pm (unchanged)
Skip blib/lib/WSSecurity/SecuritySerializer.pm (unchanged)
DEBUG: man=blib/man3/ONVIF::Serializer::Base.3pm mtime=1766866201.99901, pod=lib/ONVIF/Serializer/Base.pm mtime=1765495870, Makefile mtime=undef
Use of uninitialized value in numeric gt (>) at /usr/lib64/perl5/5.42/ExtUtils/Command/MM.pm line 147.
Manifying 1 pod document

Given gentoo's ebuild scripts, I don't believe that Makefile will ever exist within the build sandbox. We're not dependent upon it.

So if we want to be surgical, Line 149 might be all we need.
I can test this further...

(mtime($man) > (mtime("Makefile") // 0)) );`

Again. this is more of an annoyance pollution than actual breakage. As the build process continues post uninitialized

[nabbi]

@Leont thanks for questioning mtime.

I refined the PR, this is boiling down to no Makefile present / needed during portage builds.

[Leont]

I think that «make -f MakefilePerl» is the essential clue here. Zoneminder is explicitly giving it a silly name in the CMakeLists.txt, and then ExtUtils::Command::MM doesn't know about that name.

A better fix might be to pass on the FIRST_MAKEFILE argument to pod2man, and use that instead of a hardcoded 'Makefile'. Though I'm really curious why they chose to rename it in the first place.

Regardless of any of that, modules under cpan/ have their upstream elsewhere, and bugs/prs should be there.

[nabbi]

Appreciate the insights. Opened Perl-Toolchain-Gang/ExtUtils-MakeMaker#479

Do we want this //0 hack as a PR or ponder further ?

[jkeenan]

Appreciate the insights. Opened Perl-Toolchain-Gang/ExtUtils-MakeMaker#479

Do we want this //0 hack as a PR or ponder further ?

My hunch is that that is better discussed in the Perl-Toolchain-Gang issue you just opened.

Here in Perl 5 Porters Land, we're concerned with the impact of ExtUtils-MakeMaker (including ExtUtils::Command::MM) on the code that ships with the Perl core distribution. ExtUtils-MakeMaker is, however, "dual-life, upstream," meaning that its primary maintenance is on CPAN and that people are free to install the latest CPAN version of the library on older versions of Perl. That means, at least in principle, that any patch/pull request you provide upstream will be assessed over a wider scope of use-cases than we would undertake here (even though the "we" in this case is often the same people).

[connortechnology]

I think we do this because cmake creates a Makefile in the same directory. @nabbi are you using cmake? I don't see how any of this could work if Makefile doesn't exist.

[nabbi]

Yes; using gentoo ebuild, src_compile function calls cmake_src_compile to initiate "cmake".

What I believe is happening is the CMakeLists.txt writes that file as "MakefilePerl".... then ExtUtils/Command/MM.pm throws uninitialized values as it's not finding it exactly as "Makefile". By default, that uninitialized behaviors still passes the greater than > check within MM.pm and the zoneminder build process continues, but with noise.

Cross linking ZoneMinder/zoneminder#4507 so there's triangulation for others following along.