[MacPorts] #63384: espeak-ng @1.50: phsource/intonation': No such file or directory.

[MacPorts]

#63384: espeak-ng @1.50: phsource/intonation': No such file or directory.
------------------------------+--------------------
  Reporter:  Git-Christopher  |      Owner:  (none)
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:
Resolution:                   |   Keywords:
      Port:  espeak-ng        |
------------------------------+--------------------

Comment (by ryandesign):

 In this case, I don't believe that helps.

 This build system finishes by running the compiled espeak-ng program:

 {{{
 :info:build
 ESPEAK_DATA_PATH=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
 .org_macports_release_tarballs_ports_audio_espeak-ng/espeak-ng/work
 /espeak-ng-1.50 src/espeak-ng --compile-intonations && \
 :info:build
 ESPEAK_DATA_PATH=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
 .org_macports_release_tarballs_ports_audio_espeak-ng/espeak-ng/work
 /espeak-ng-1.50 src/espeak-ng --compile-phonemes && \
 :info:build             touch phsource/phonemes.stamp
 }}}

 It needs to know where its data is. At build time, it has not been
 installed yet, so the path to the data is within the build directory; it
 sets the ESPEAK_DATA_PATH environment variable to this value. The length
 of that path is pretty long in a standard MacPorts install:
 "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
 .org_macports_release_tarballs_ports_audio_espeak-ng/espeak-ng/work
 /espeak-ng-1.50/" per this user's log is 159 characters, but if a user
 uses a different MacPorts mirror it would be even longer. esound-ng uses a
 fixed-size character array to store the path that it gets from this
 environment variable, concatenated with the further 15 characters
 "/espeak-ng-data". The fixed size of the character array is 160 bytes (the
 #define is N_PATH_HOME), so in a standard MacPorts install, the path
 length exceeds the size of the array. The program is smart enough to
 detect that a memory overflow would occur and does not attempt to put the
 value into the variable, but it is evidently not smart enough to abort
 with an error explaining what the problem is.

 So in fact there is nothing unusual about the user's system that makes
 this fail; rather, there is something unusual about my system and the
 buildbot systems that makes it succeed there, namely that they use shorter
 build paths because they use ports trees in non-standard locations. On my
 system, the path to the source directory is only 129 characters and on the
 buildbot it is only 122 characters.

 It's unclear why N_PATH_HOME is set to 160. The size has already been
 increased twice over the years; it was previously 150, and 120 before
 that. And there is already a conditional that sets it much higher on
 Windows. It seems like the fix is just to increase this variable's size
 considerably. Conferring with upstream is probably a good idea.
 Alternately, a fix could be to set ESPEAK_DATA_PATH to a relative path.

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