On Sep 6, 2014, at 10:14 PM, Kurt Hindenburg wrote:
> On 9/6/14, 9:03 PM, Ryan Schmidt wrote:
>>> tclx: update to 8.4.1 - use tcl8.6.2 source (not sure hard coding this is a
>>> good idea as I have tcl8.6.1 installed) - no ports that depend on this
>>> currently build - #44831 #33203 #38603
>>
>> Many ports that use tcl also need the tcl source code (to get the "private"
>> headers, which are apparently not that private since everybody uses them),
>> and they hardcode the tcl version. What other solution would you suggest?
>
> Anything like this for tcl? {python.version} {perl5.major} or similar?
Those variables are features of the python and perl5 portgroups respectively;
there isn't a tcl portgroup. If we made a tcl portgroup, what would it contain?
At the moment it seems like it would just contain the code to add the current
Tcl distfile and checksums. This might be slightly tricky to implement, since
portfile authors usually overwrite checksums in their portfiles, and
overwriting distfiles is not uncommon either. We would either have to switch
those ports to append to those variables instead of overwriting, or else do
something clever with variable traces to second-guess the author's intentions
(like we do in some of the other portgroups already).
If we manage to work out those issues, then the question becomes what should
happen when the Tcl version is changed in the portgroup. Should we assume that
all ports that use that source will still build, and that furthermore they will
build exactly the same as they would with any other version of Tcl? That may be
an unjustified leap of faith. If it's possible that ports will build
differently when using different versions of Tcl private headers, then the
ports using this hypothetical portgroup would need a revbump whenever the Tcl
version in the portgroup is changed. If it's possible that ports will fail to
build with different versions of Tcl private headers, then each port may need
testing to verify compatibility with each update. Possibly this is all
unnecessary and it'll work fine. The biggest problem we currently have, which
this solution would avoid, is that of having ports still using the Tcl 8.4 or
8.5 headers when the version of Tcl in MacPorts is 8.6. A major version
mismatch like that is probably bad.
An alternate strategy to the above would be to just have the Tcl port install
the private headers, maybe in an unusual location, so that ports that need them
can get at them without needing their own copy of the Tcl source.
On Sep 7, 2014, at 9:25 AM, Brandon Allbery wrote:
> On Sun, Sep 7, 2014 at 2:12 AM, Lawrence Velázquez wrote:
>> On Sep 7, 2014, at 1:35 AM, Brandon Allbery wrote:
>>> Perhaps more to the point, the fact that MacPorts itself uses Tcl means
>>> that it's much harder to deal with multiple versions. (As it is, I think
>>> recently it started installing its own to avoid conflicts with varying
>>> Apple versions etc.?)
>>
>> Correct, MacPorts now installs a private copy of Tcl for its own use.
>
> Actually that implies what I said is wrong, if that private copy is not the
> same as a Tcl port.
Right, this isn't a problem. MacPorts has always used a different Tcl than that
provided by the MacPorts tcl port. It used to be the Tcl provided by OS X
(version 8.4 or 8.5 depending on OS X version), and now as of MacPorts 2.3.0
it's a private copy of Tcl (8.5) installed by MacPorts. Doesn't matter what the
tcl port does (currently version 8.6, with which MacPorts base is currently
incompatible).
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
