[MacPorts] #61253: configuring base requires working tclsh

[MacPorts]

#61253: configuring base requires working tclsh
-------------------------+--------------------
  Reporter:  ryandesign  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  base        |    Version:  2.6.99
Resolution:              |   Keywords:
      Port:              |
-------------------------+--------------------
Description changed by ryandesign:

Old description:

> It was a surprise to me to discover that tcllib's configure script, which
> our configure script runs, requires a working tclsh, and that if
> ${prefix}/libexec/macports/bin/tclsh8.5 exists, it will choose that one.
> This is a problem when ${prefix}/libexec/macports/bin/tclsh8.5 exists but
> is broken, which was the case on my system and was one of the reasons why
> I was trying to rebuild from source.
>
> The symptom was:
>
> {{{
> Installing Tcllib 1.18
> You have chosen the following configuration ...
>
> Packages:      /Users/rschmidt/macports-base/vendor/vendor-
> destroot/opt/local/libexec/macports/lib/.
> Applications:  Not installed.
> Examples:      Not installed.
> Documentation: Not installed.
> [snip]
> chmod: /Users/rschmidt/macports-base/vendor/vendor-
> destroot/opt/local/libexec/macports/lib/tcllib*: No such file or
> directory
> }}}
>
> The packages path is wrong! It should not end with `lib/.`; it should end
> with `lib/tcllib1.18`.
>
> tcllib's configure script replaces placeholder strings `@PACKAGE@` and
> `@VERSION@` with values computed by a script called sak.tcl. The version
> is composed of the major version, then a literal dot, then the minor
> version. Since in my case tclsh did not work, the package, major and
> minor version strings were empty, leaving only the literal dot.
>
> Apple has announced that scripting languages like tclsh won't necessarily
> be included in future versions of macOS. We should modify our build
> process so that we first build tclsh, and only then do we configure
> tcllib and point it at the tclsh that we built.

New description:

 It was a surprise to me to discover that tcllib's configure script, which
 our configure script runs, requires a working tclsh, and that if
 ${prefix}/libexec/macports/bin/tclsh8.5 exists, it will choose that one.
 This is a problem when ${prefix}/libexec/macports/bin/tclsh8.5 exists but
 is broken, which was the case on my system and was one of the reasons why
 I was trying to rebuild from source.

 The symptom was:

 {{{
 Installing Tcllib 1.18
 You have chosen the following configuration ...

 Packages:      /Users/rschmidt/macports-base/vendor/vendor-
 destroot/opt/local/libexec/macports/lib/.
 Applications:  Not installed.
 Examples:      Not installed.
 Documentation: Not installed.
 [snip]
 chmod: /Users/rschmidt/macports-base/vendor/vendor-
 destroot/opt/local/libexec/macports/lib/tcllib*: No such file or directory
 }}}

 The packages path is wrong! It should not end with `lib/.`; it should end
 with `lib/tcllib1.18`.

 tcllib's configure script replaces placeholder strings `@PACKAGE@` and
 `@VERSION@` with values computed by a script called sak.tcl. The version
 consists of the major version, then a literal dot, then the minor version.
 Since in my case tclsh did not work, the package, major and minor version
 strings were empty, leaving only the literal dot.

 My workaround was to move the directory ${prefix} to ${prefix}old, then
 run configure and make, then move ${prefix}old back to ${prefix}, then
 sudo make install.

 Apple has announced that scripting languages like tclsh won't necessarily
 be included in future versions of macOS. We should modify our build
 process so that we first build tclsh, and only then do we configure tcllib
 and point it at the tclsh that we built.

--

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