Macports Tcl

[Ryan Schmidt]

On Jul 13, 2013, at 12:11, Gustaf Neumann wrote:
> Am 13.07.13 15:53, schrieb Lawrence Velázquez:
>> Bootstrapping from source would be weird, for one. I suppose we'd bundle Tcl with the source, install using that one, install the Tcl port, and reinstall off of the port? It sounds gross, but it would only have to happen for the initial install.
> not sure, i understand correctly. If you suggest to run port
> itself on its own port, this can be dangerous:
> - a user might deinstall tcl and that would kill ports alltogether
> - if someone installs a broken tcl-port, everything will be broken.
> - the tcl port is currently just called "tcl" (not tcl84, tcl85 or tcl86),
>  so the macports team has verly little control, what version
>  of tcl is being used.
> - tcl has variants. The user variant which might or might
>  not be the same as the one that macports has..
> 
> There are probably many more such reasons.

Right, all of those concern me, and would be reasons why I would *not* want a hypothetical future self-hosted MacPorts port to depend on any other port: tcl, curl, whatever.


> Having an own, separate copy for macports and nobody else
> seems to me pretty robust.

Yes. So assuming we work now on putting a good copy of Tcl and maybe cURL into the MacPorts source distribution and build system, and installing it into libexec, then when it comes time to update the MacPorts port, nothing really changes: it still just has to configure, make and make install, which puts everything where it needs to go, self-contained within the MacPorts port. I like this.