[MacPorts] #71193: Experimental p5.38-mac-systemdirectory does not build for testing on macOS High Sierra, version 10.13.6, because of wrong input/answer?

[MacPorts]

#71193: Experimental p5.38-mac-systemdirectory does not build for testing on macOS
High Sierra, version 10.13.6, because of wrong input/answer?
----------------------------------------+------------------------
  Reporter:  ballapete                  |      Owner:  (none)
      Type:  defect                     |     Status:  new
  Priority:  Normal                     |  Milestone:
 Component:  ports                      |    Version:  2.10.2
Resolution:                             |   Keywords:  highsierra
      Port:  p5.38-mac-systemdirectory  |
----------------------------------------+------------------------

Comment (by ballapete):

 I solved the problems of building the module with an additional set of
 patches:

 {{{
 --- SystemDirectory.xs~ 2022-02-21 06:33:28.000000000 +0100
 +++ SystemDirectory.xs  2024-12-14 13:47:36.000000000 +0100
 @@ -5,11 +5,11 @@

  #ifdef Move
  #  undef Move
 -#endif Move
 +#endif

  #ifdef I_POLL
  #  undef I_POLL
 -#endif I_POLL
 +#endif

  #import <Foundation/Foundation.h>

 @@ -124,6 +124,11 @@
          case NSPreferencePanesDirectory:
          case NSItemReplacementDirectory:
  #endif
 +#if (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 101300)
 +        case NSAutosavedInformationDirectory:
 +        case NSApplicationScriptsDirectory:
 +        case NSTrashDirectory:
 +#endif
          {
              NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
              NSArray *paths =
 NSSearchPathForDirectoriesInDomains(directory, domainMask, YES);
 }}}

 Presumingly the original patch, patch-macos-10.10+.diff, is OK. My first
 report already contains:

 {{{
 override rw-r--r--  root/wheel for SystemDirectory.m? (y/n [n]) not
 overwritten
 }}}

 This file is created in the `build phase`:

 {{{
   -rw-r--r-- 1 macports macports 25454 21. Feb 2022  META.yml
   -rw-r--r-- 1 macports macports 43928 14. Dez 23:31 MYMETA.json
   -rw-r--r-- 1 macports macports 25416 14. Dez 23:31 MYMETA.yml
   -rw-r--r-- 1 macports macports 39172 14. Dez 23:31 Makefile
   -rw-r--r-- 1 macports macports  2239 21. Feb 2022  Makefile.PL
   -rw-r--r-- 1 macports macports   387 21. Feb 2022  README
   -rw-r--r-- 1 macports macports     0 14. Dez 23:31 SystemDirectory.bs
   -rw-r--r-- 1 macports macports 12550 14. Dez 23:31 SystemDirectory.m
   -rw-r--r-- 1 macports macports 11284 14. Dez 23:31 SystemDirectory.o
   -rw------- 1 macports macports  5666 14. Dez 23:31 SystemDirectory.xs
   drwxr-xr-x 8 macports macports   272 14. Dez 23:31 blib
   -rw------- 1 macports macports  1700 21. Feb 2022  dist.ini
   drwxr-x--- 3 macports macports   102 21. Feb 2022  inc
   drwxr-x--- 3 macports macports   102 21. Feb 2022  lib
   -rw-r--r-- 1 macports macports     0 14. Dez 23:31 pm_to_blib
 }}}

 You can see that the permissions are alright. After the `install -k phase`
 the permissions are *not* OK:

 {{{
   -rw-r--r-- 1 macports macports 25454 21. Feb 2022  META.yml
   -rw-r--r-- 1 macports macports 43928 14. Dez 23:31 MYMETA.json
   -rw-r--r-- 1 macports macports 25416 14. Dez 23:31 MYMETA.yml
   -rw-r--r-- 1 macports macports 39172 14. Dez 23:31 Makefile
   -rw-r--r-- 1 macports macports  2239 21. Feb 2022  Makefile.PL
   -rw-r--r-- 1 macports macports   387 21. Feb 2022  README
   -rw-r--r-- 1 macports macports     0 14. Dez 23:31 SystemDirectory.bs
   -rw-r--r-- 1 root     macports 12550 14. Dez 23:34 SystemDirectory.m
   -rw-r--r-- 1 root     macports 11284 14. Dez 23:34 SystemDirectory.o
   -rw------- 1 macports macports  5666 14. Dez 23:31 SystemDirectory.xs
   drwxr-xr-x 8 macports macports   272 14. Dez 23:31 blib
   -rw------- 1 macports macports  1700 21. Feb 2022  dist.ini
   drwxr-x--- 3 macports macports   102 21. Feb 2022  inc
   drwxr-x--- 3 macports macports   102 21. Feb 2022  lib
   -rw-r--r-- 1 macports macports     0 14. Dez 23:31 pm_to_blib
 }}}

 Clearly a bug in MacPorts. Could be here?

 {{{
 make: Entering directory
 `/opt/local/var/macports/build/_Users_alpha_ports_perll_p5-mac-
 systemdirectory/p5.34-mac-systemdirectory/work/Mac-SystemDirectory-0.14'
 "/opt/local/bin/perl5.34" -MExtUtils::Command::MM -e 'cp_nonempty' --
 SystemDirectory.bs blib/arch/auto/Mac/SystemDirectory/SystemDirectory.bs
 644
 "/opt/local/bin/perl5.34" "/opt/local/lib/perl5/5.34/ExtUtils/xsubpp"
 -typemap '/opt/local/lib/perl5/5.34/ExtUtils/typemap'  SystemDirectory.xs
 > SystemDirectory.xsc
 mv SystemDirectory.xsc SystemDirectory.c
 mv SystemDirectory.c SystemDirectory.m
 /usr/bin/clang -c   -fno-common -DPERL_DARWIN -pipe -Os -fno-strict-
 aliasing -fstack-protector-strong -I/opt/local/include
 -DPERL_USE_SAFE_PUTENV -arch x86_64 -isysroot/ -O3   -DVERSION=\"0.14\"
 -DXS_VERSION=\"0.14\"  "-I/opt/local/lib/perl5/5.34/darwin-thread-multi-
 2level/CORE"  -DHAS_BOOL SystemDirectory.m
 r}}}

 Two moves, and the file is owned by root! Clang then simply copies
 ownership to its output file? Or another MacPorts bug?

 And so the `test phase` cannot succeed…

-- 
Ticket URL: <https://trac.macports.org/ticket/71193#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS