[MacPorts] #72155: z3 @4.13.4: error: Error in reading profile .../z3.profdata: No such file or directory (was: z3 @4.13.4 fails to build)

[MacPorts]

#72155: z3 @4.13.4: error: Error in reading profile .../z3.profdata: No such file
or directory
---------------------+--------------------
  Reporter:  lpgaff  |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.10.5
Resolution:          |   Keywords:
      Port:  z3      |
---------------------+--------------------

Comment (by ryandesign):

 I agree, the z3 port gets the same error on our automated build machines.

 Looks like it was intended that the port would extract the profile file
 from an archive in the files directory, however in the case of the z3 port
 the archive name that is selected doesn't exist:

 {{{
 :debug:extract Executing proc-post-org.macports.extract-extract-0
 :debug:extract system: /opt/local/bin/xz -cd
 /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/math/z3/files/.profdata.tar.xz
 | /usr/bin/tar -C
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_z3/z3/work
 --no-same-owner -xf -
 :info:extract /opt/local/bin/xz:
 /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/math/z3/files/.profdata.tar.xz:
 No such file or directory
 }}}

 The Portfile code is:

 {{{#!tcl
 system "${xz} -cd ${filespath}/${z3.pgo_profile}.profdata.tar.xz | ${tar}
 -C ${workpath} --no-same-owner -xf -"
 }}}

 So evidently here the `${z3.pgo_profile}` variable is unexpectedly empty.

 The error is not detected by the extract phase because the error comes
 from `xz` and is swallowed up by the pipe (`|`). `tar` then receives no
 input on stdin and evidently considers that to be no problem and exits
 with the success code (`0`), so MacPorts proceeds to the configure phase
 which fails due the missing file that didn't get extracted.

 Incidentally, it has been forgotten here to use `[shellescape]` for all
 variables that are being used in the `system` call.

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