[125111] trunk/dports/lang/tclx/Portfile

[Ryan Schmidt]

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).