tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Accurate info about Tcl

[Torsten B. <be...@ty...>]

Hi,

thanks for pushing the macOS side of Tcl!

I have never built Tcl using the Xcode IDE. However, the install instructions (macosx/README) in the core distribution implicitly and between the lines suggest this should be possible. It says "To build universal binaries outside of the Xcode IDE ..." as if it should be possible to also build it with the IDE. There are, nonetheless, no instructions on how to do this. Maybe the wording could be enhanced or rather it can be made explicit that this is not the case.

(Actually, the README file also still used the outdated "MAC OS X" and I always wonder whether the information is correct saying that you need "at least Mac OS X 10.3 [...] to build Tcl" and "At a minimum, Mac OS X 10.3 is required to run Tcl". I remember the discussion leading to https://core.tcl-lang.org/tips/doc/trunk/tip/715.md where macOS 10.15 for Intel and macOS 11 for Apple Silicon machines are documented ... oh, and "Intel silicon" on that page seems a wrong term as it is about the x86 architecture)

As to the term "Mac OS X" on the website (and elsewhere). I have already made the necessary changes to the files for the web pages a while ago. Unfortunately, Steve (who initiated this process) has too much real life work on his desk to actually review my changes and publish them. Should this perhaps be delegated to someone else? My changes also include many more clarifications etc., deleting outdated stuff, suggesting additions and clarifications and so on. Someone from the TCT (?) just needs to take the time and dedication to go through it all.

I am willing to help updating documentation if I get a mandate.

Regards, Torsten


> Am 17.06.2025 um 00:50 schrieb Marc Culler <cul...@gm...>:
> 
> Sorry for nitpicking and harping on this general subject, but ...
> 
> On the page https://www.tcl-lang.org/software/tcltk/download.html one finds the statement (with emphasis added by me):
> 
>> The source releases include make files for Windows, Unix and Xcode project files for Mac OS X.
> 
> There are no Xcode project files that I can find.  I don't think anyone builds Tcl or Tk as an Xcode project anymore.  People either use the Command Line Tools or a compiler, linker and SDK provided with the Xcode app.  But I don't think anyone uses the Xcode IDE, and there is no support for doing that in the source archive.
> 
> Also, the Apple OS has been named macOS since 2016.
> 
> - Marc
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Accurate info about Tcl

[Marc C. <cul...@gm...>]

Sorry for nitpicking and harping on this general subject, but ...

On the page https://www.tcl-lang.org/software/tcltk/download.html one finds
the statement (with emphasis added by me):

The source releases include make files for Windows, Unix and Xcode project
> files for Mac OS X.


There are no Xcode project files that I can find.  I don't think anyone
builds Tcl or Tk as an Xcode project anymore.  People either use the
Command Line Tools or a compiler, linker and SDK provided with the Xcode
app.  But I don't think anyone uses the Xcode IDE, and there is no support
for doing that in the source archive.

Also, the Apple OS has been named macOS since 2016.

- Marc

Re: [TCLCORE] More on TEA packages for macOS

[Marc C. <cul...@gm...>]

Right.  It would be a correct answer to a different, largely unrelated
question.

But the point is that these things spend millions of cpu hours munching on
the entire internet.  So their answers reflect the information about this
topic which is potentially available to users who don't have
special knowledge about where to look.

- Marc

On Mon, Jun 16, 2025 at 2:23 PM Kevin Walzer <kw...@54...>
wrote:

> This is correct for the frameworks themselves, but not external packages.
>
> On Jun 16, 2025, at 3:10 PM, Marc Culler <cul...@gm...> wrote:
>
> 
> Of course we all expect wrong and missing information from AI
> assistants, and expect different people to get different answers.  But I
> think many people depend on those critters.  So it may be relevant to
> report what google's "AI overview" said when I asked "What is the standard
> location for a Tcl package on macOS?".
>
> *AI Overview*
> On macOS, Tcl packages can be found in several standard locations,
> primarily within the system's framework directories
> . The main directories where you'll find them are:
>
>    - */Library/Frameworks*: This is the default location for third-party
>    or built-from-source frameworks, including ActiveTcl releases.
>    - */System/Library/Frameworks*: This directory contains Apple-supplied
>    frameworks that come with macOS. *Note:* You should generally avoid
>    modifying or deleting files in this directory.
>    - *$HOME/Library/Frameworks*: You might also find Tcl and Tk
>    frameworks in your user's Library directory.
>
> - Marc
>
> PS The stupidest part is warning people against modifying files in
> /System/Library/Frameworks, as if that were even possible.
>
> On Mon, Jun 16, 2025 at 1:36 PM Marc Culler <cul...@gm...> wrote:
>
>> On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer <kw...@54...>
>> wrote:
>>
>> You can pass —libdir as a flag to configure to set the install dir.
>>>
>>
>> I guess you mean that you can do that when configuring an extension that
>> you build locally?
>>
>>
>>> I think the default directory is /usr/local if not otherwise defined.
>>> Either way, I’m not a fan of putting external stuff in the frameworks.
>>>
>>
>> I still don't know why you are not a fan.  However, the issue of what
>> should be the default install location actually runs pretty deep at the
>> moment, as I explain below.
>>
>> I recently committed a change to the tcllib repository to fix ticket [
>> e5f3dfc055
>> <https://fedbdhd.r.af.d.sendibt2.com/tr/cl/Ft28etyuAswveDuhHepGdF2VamfIZgnfmqtyPnoxSESmIm1oI69CPRO6r5YbfO9K5AMRXxaUYI95oegCeFwMQeSjZ8ZZwdw0_9KMtqdJ9Rr6JoNYgu-YtoMC2TiFtKk0gsG9gtvEKEWekt3tvFtmGhIIrmnGXibWJ8y5WkJ5s78CQiew4aNqOBbk0QzIJ5j7hmV0bLG3CyIiw5dIvSW1HvYN4N-Hg9jGO5d1RLk0Un5UTBdXHi_g5R7cCRIYFGimbkrn5bhFOpvAoHK9xLx9IlfibdREQ7cAChwHWME1GqrYiMU>],
>> posted by Ashok a year ago, which was reporting that the Tcllib installer
>> does not work "out of the box".  That means that the installer script would
>> fail if you used its default install path, although you could edit the path
>> if you happened to know where you wanted to install Tcllib. I think it is
>> pretty clear that the default path for the Tcllib installer **should** be
>> the "standard location" for Tcl packages, whatever that is.
>>
>> The reason that the installer script did not work was that it was
>> choosing the zipfs as the install location on Windows and Linux, and the
>> path /Library/Frameworks/Tk.framework/Versions on macOS.  It makes no sense
>> to install a package in the zipfs and it also makes no sense to install a
>> pure Tcl package in the Tk framework.  Moreover installing it in the
>> Versions directory completely corrupts the structure of the Tk framework.
>>
>> The fix was to take the default install path to be the first item on the
>> auto_path which does not begin with '//zipfs:'.  That works on all
>> systems.  But it also means that on macOS the default location for
>> installing Tcllib
>> becomes /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.
>>
>> I am trying to argue that we need a *real* (documented) standard location
>> and that we should actually think hard about what it should be.
>>
>> I am also trying to argue that we should make package installation
>> cleaner and easier.
>>
>> Comment for Schelte:  It if were as easy to install a Tcl package as it
>> is to install a Python or Ruby package, then it would be much easier to
>> declare that useful additions should be extensions rather than part of the
>> core.  But I claim that only an elite subset of Tcl/Tk experts actually
>> know how to successfully install a Tcl/Tk package.  And I claim that there
>> is currently no standard way to do that.
>>
>> - Marc
>>
>> PS I have learned a lot from wiki pages, but only when someone has
>> provided me with a direct link to a specific wiki page.  I don't have much
>> luck finding anyting useful on the wiki by starting at the top, and I
>> suspect that I am not alone in that respect.  So I don't consider the wiki
>> to be real documentation nor a place for a specification of something like
>> what the default paths for installing Tcl packages should be on various
>> operating systems.
>>
>>
>>
>>>
>>> —Kevin
>>>
>>> On Jun 16, 2025, at 12:13 PM, Marc Culler <cul...@gm...> wrote:
>>>
>>> 
>>> Hi Kevin,
>>>
>>> I am not sure that convention makes sense anymore, given that
>>> /usr/bin/tclsh could not load any extension built for a currently supported
>>> version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
>>> is buried deep in the auto_path suggests that we are not really supporting
>>> it now.  (I realize that different versions of Tcl could be supported in
>>> subdirectories of /Library/Tcl, but I still think that, de facto, we are
>>> not really supporting it.)  Supporting multiple versions is also a feature
>>> of a framework.
>>>
>>> I think that being self-contained is a very good feature of a binary
>>> distribution.  And I think it would be a good thing for Tcl/Tk to once
>>> again be installable by downloading a single .pkg file and clicking on it.
>>> And it would be good for such an installation to be able to add packages
>>> without losing the property of being self-contained.  So I think we should
>>> do what we can to facilitate moving in that direction.
>>>
>>> I note that this sort of installation scheme works well for Python,
>>> which now embeds framework builds of Tcl and Tk within the
>>> Python.framework. (Nested frameworks are allowed and encouraged by Apple,
>>> but not as Resources.)
>>>
>>> - Marc
>>>
>>> On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
>>> wrote:
>>>
>>>> Marc,
>>>>
>>>> It’s an older convention from the early days of macOS when Tcl/Tk was
>>>> included and actively maintained in the system. The /Library/Tcl path was
>>>> picked up by both the system installation and a locally installed build.
>>>> Same principle applies to Perl, Python etc.
>>>>
>>>> The wiki FAQ I wrote also references this in build instructions for
>>>> extensions:
>>>>
>>>> New Tcl/TkAqua FAQ
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
>>>> wiki.tcl-lang.org
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
>>>> <favicon.ico>
>>>>
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>>>>
>>>> —Kevin
>>>>
>>>> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>>>>
>>>> 
>>>> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
>>>> wrote:
>>>>
>>>>> The canonical installation location for extension packages is
>>>>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>>>>
>>>>
>>>> Hi Kevin,
>>>>
>>>> Where do you find that canonical location specified?  And why shouldn't
>>>> they go in the framework?
>>>>
>>>> Using that location seems to destroy one of the great advantages of
>>>> using a framework - namely that all dependencies are contained in the
>>>> framework.  Removing a framework should not involve hunting throughout the
>>>> system for hidden dependencies which should be removed along with the
>>>> framework because they become useless once the framework is gone.
>>>>
>>>> My system does not have a /Library/Tcl directory, nor does it have a
>>>> /Library/Python directory.  (Those two languages get installed as
>>>> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
>>>> and /Library/Java.
>>>>
>>>> - Marc
>>>>
>>>>

Re: [TCLCORE] More on TEA packages for macOS

[Kevin W. <kw...@co...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.bh.d.sendibt3.com/tr/op/MJpZV5DnKeOWbyDCpTy8cxxJSBke-yShUVBCcAi7uDisbUYnPYmfm5MSgxhgL4THDBDNLQZ5JzcF0ERa_ysLEGemdInIGAga45cr108WLnUo3t1WT4bGrEHRnLC_aj0z66NLSfmjkOHlrpckj9gflu3XxRpbWxIbBGcnfst7HYWkWKKzUzbIQ9Dt2o8diZOMRV8Tavtj_VIk4ivxa6vO104aPUhlT48o" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">This is correct for the frameworks themselves, but not external packages.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 3:10 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Of course we all expect wrong and missing information from AI assistants,&nbsp;and expect different people to get&nbsp;different answers.&nbsp; But I think many people depend on those critters.&nbsp; So it may be relevant to report what google's "AI overview" said when I asked "What is the standard location for a Tcl package on macOS?".</div><div><br></div><div><div class="gmail-nk9vdc" style="flex-grow: 1;"><div class="gmail-Fzsovc gmail-cwYVJe gmail-RJPOee" role="heading" style="animation: none;"><strong>AI Overview</strong></div></div><div class="gmail-nk9vdc"><div class="gmail-QZvcUb"><div><div><div><div><div><div class="gmail-H4fljf" aria-label="About this result" role="button" tabindex="0"><span class="gmail-xC2q7c gmail-z1asCe gmail-SaPW2b" style="height:18px;line-height:18px;width:18px"></span></div></div></div></div></div></div></div></div><div class="gmail-EyBRub gmail-jUja0e gmail-aPfNm"><div class="gmail-Pqkn2e gmail-rNSxBe"><div class="gmail-jloFI gmail-GkDqAd"><div><div><div><div class="gmail-scm-c"><div class="gmail-UxeQfc"><div class="gmail-LT6XE"><div class="gmail-RJPOee gmail-EIJn2" style="animation: none;"><div><div><span></span> <div>  <div> <div class="gmail-qRuFed"><div class="gmail-Zkbeff"><div class="gmail-pWvJNd"><div class="gmail-mZJni"><div class="gmail-Y3BBE"><div style="display:contents">On macOS, Tcl packages can be found in several standard locations, primarily within the system's framework directories</div>.  The main directories where you'll find them are:<span class="gmail-"><span class="gmail-vKEkVd">&nbsp;</span></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail-Y3BBE"><span class="gmail-"></span></div><ul class="gmail-U6u95"><li><span class="gmail-T286Pc"><b class="gmail-Yjhzub">/Library/Frameworks</b>: This is the default location for third-party or built-from-source frameworks, including ActiveTcl releases.</span></li><li><span class="gmail-T286Pc"><b class="gmail-Yjhzub">/System/Library/Frameworks</b>:  This directory contains Apple-supplied frameworks that come with macOS. <b class="gmail-Yjhzub">Note:</b> You should generally avoid modifying or deleting files in this directory.</span></li><li><span class="gmail-T286Pc"><b class="gmail-Yjhzub">$HOME/Library/Frameworks</b>: You might also find Tcl and Tk frameworks in your user's Library directory.</span><span class="gmail-"><span class="gmail-vKEkVd">&nbsp;</span></span></li></ul>- Marc</div><div><br></div><div>PS The stupidest&nbsp;part is warning people against modifying files in /System/Library/Frameworks, as if that were even possible.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 16, 2025 at 1:36 PM Marc Culler &lt;<a href="mailto:cul...@gm...">cul...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">You can pass —libdir as a flag to configure to set the install dir.</div></div></blockquote><div><br></div><div>I guess you mean that you can do that when configuring an extension that you build locally?</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"> I think the default directory is /usr/local if not otherwise defined. Either way, I’m not a fan of putting external stuff in the frameworks.</div></div></blockquote><div><br></div><div>I still don't know why you are not a fan.&nbsp; However, the issue of what should be the default install location actually runs pretty deep at the moment, as I explain below.</div><div><br></div><div>I recently committed a change to the tcllib repository to fix ticket [<a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/LhZ8QeqimXUgr3xhpE5sRa_F2b9dZRaB5hKOtVB6bYmigyHzSvBXo-77hCnUUq9oU-9ieTefRBjRyvLaxTqd-T0ZdvyRJ4LyZ2sQQ2_S6-NJ-0FWIXRLi7tJoCmDLeorZTd_vXgPSdSSzdP5OXJEisXZ3U1sP04CC67EIbz3marLZkQDYzUG6J9U5ng0ydILik92XxUc6Cv7rYUt4ltinkO2jIrpNIvB6MtmMuFeMPwXQW-NyFUV0J93pKV063RgaFAwmLq-nRq6hlNEJdAriRST5E708qOKNchUNAjiKEmhEeArhjAJ1vv7cXq5Dl0" target="_blank">e5f3dfc055</a>], posted by Ashok a year ago, which was reporting that the Tcllib installer does not work "out of the box".&nbsp; That means that the installer script would fail if you used its default install path, although you could edit the path if you happened to know where you wanted to install Tcllib. I think it is pretty clear that the default path for the Tcllib installer **should** be the "standard location" for Tcl packages, whatever that is.&nbsp;</div><div><br></div><div>The reason that the installer script did not work was that it was choosing the zipfs as the install location on Windows and Linux, and the path /Library/Frameworks/Tk.framework/Versions on macOS.&nbsp; It makes no sense to install a package in the zipfs and it also makes no sense to install a pure Tcl package in the Tk framework.&nbsp; Moreover installing it in the Versions directory completely corrupts the structure of the Tk framework.</div><div><br></div><div>The fix was to take the default install path to be the first item on the auto_path which does not begin with '//zipfs:'.&nbsp; That works on all systems.&nbsp; But it also means that on macOS the default location for installing Tcllib becomes&nbsp;/Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.</div><div><br></div><div>I am trying to argue that we need a *real* (documented) standard location and that we should actually think hard about what it should be.</div><div><br></div><div>I am also trying to argue that we should make package installation cleaner and easier.</div><div><br></div><div>Comment for Schelte:&nbsp; It if were as easy to install a Tcl package as it is to install a Python or Ruby package, then it would be much easier to declare that useful additions should be extensions rather than part of the core.&nbsp; But I claim that only an elite subset of Tcl/Tk experts actually know how to successfully install a Tcl/Tk package.&nbsp; And I claim that there is currently no standard way to do that.</div><div><br></div><div>- Marc</div><div><br></div><div>PS I have learned a lot from wiki pages, but only when someone has provided me with a direct link to a specific wiki page.&nbsp; I don't have much luck finding anyting useful on the wiki by starting at the top, and I suspect that I am not alone in that respect.&nbsp; So I don't consider the wiki to be real documentation nor a place for a specification of something like what the default paths for installing Tcl packages should be on various operating systems.</div><div><br></div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 12:13 PM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hi Kevin,</div><div><br></div><div>I am not sure that convention makes sense anymore, given that /usr/bin/tclsh could not load any extension built for a currently supported version of Tcl and that /usr/bin/wish crashes.&nbsp; Also the fact that the path is buried deep in the auto_path suggests that we are not really supporting it now.&nbsp; (I realize that different versions of Tcl could be supported in subdirectories of /Library/Tcl, but I still think that, de facto, we are not really supporting it.)&nbsp; Supporting multiple versions is also a feature of a framework.</div><div><br></div><div>I think that being self-contained is a very good feature of a binary distribution.&nbsp; And I think it would be a good thing for Tcl/Tk to once again be installable by downloading a single .pkg file and clicking on it.&nbsp; And it would be good for such an installation to be able to add packages without losing the property of being self-contained.&nbsp; So I think we should do what we can to facilitate moving in that direction.</div><div><br></div><div>I note that this sort of installation scheme works well for Python, which now embeds framework builds of Tcl and Tk within the Python.framework. (Nested frameworks are allowed and encouraged by Apple, but not as Resources.)</div><div><br></div><div>- Marc</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/xa8VgqvLmExlO5-JONNIHss6ysMVM1eWnXcAINJD2YKpu3HSpkjmYTo6BPc3p47Jp3o0FkV7ox0n_26J6MLmQ1BF-uVPK7CuzoOy28ZD27hqPzXEeCKJLhsCWc_jSWg7UqDC7g2KH1RJ0P1qMo8V8168IiwHngtT1ZQzSrf1t_oRTkwID00Z8L1C4LW8vfg169wfw2zch1vn" data-unique-identifier=""><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">It’s an older convention from the early days of macOS when Tcl/Tk was included and actively maintained in the system. The /Library/Tcl path was picked up by both the system installation and a locally installed build. Same principle applies to Perl, Python etc. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">The wiki FAQ I wrote also references this in build instructions for extensions:&nbsp;</div><div dir="ltr"><br></div><div dir="ltr"><div style="display:block"><div style="display:inline-block" role="link"><a style="border-radius:10px;font-family:-apple-system,Helvetica,Arial,sans-serif;display:block;width:300px;overflow:hidden;text-decoration:none" rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA" dir="ltr" role="button" width="300" target="_blank"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:rgb(161,159,156);font-family:-apple-system,Helvetica,Arial,sans-serif" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td><table bgcolor="#A19F9C" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system,Helvetica,Arial,sans-serif;background-color:rgb(161,159,156)"><tbody><tr><td style="padding:8px 0px"><div style="max-width:100%;margin:0px 16px;overflow:hidden"><div style="font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgb(255,255,255)">New Tcl/TkAqua FAQ</font></a></div><div style="font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgba(235,235,245,0.6)">wiki.tcl-lang.org</font></a></div></div></td><td style="padding:6px 12px 6px 0px" width="30"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg" target="_blank"><div>&lt;favicon.ico&gt;</div></a></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 11:17 AM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/0rJGz8a-GZcLwfiuXHRXFKgO1by8S_61Z31B3A4zOaYK-SmjMHR1Lc_ly81ohzIKV3cnJCy7So6l1SZzBfCf2LmDUJuQiZPSMneed-7IuwcL3LrvQctBGg_SxXxyrhdr6eYRbbP1PoZwmHt9_zaOWXN1jz2hySSeoy6az3T32jEJAlkAE_SobNC09ixj9XqsvF309m8ylmXc" data-unique-identifier=""></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br></blockquote><div><br></div><div>Hi Kevin,</div><div><br></div><div>Where do you find that canonical location specified?&nbsp; And why shouldn't they go in the framework?</div><div>&nbsp;</div><div>Using that location seems to destroy one of the great advantages of using a framework - namely that all dependencies are contained in the framework.&nbsp; Removing a framework should not involve&nbsp;hunting throughout the system for hidden dependencies which should be removed along with the framework because they become useless once the framework is gone.</div><div><br></div><div>My system does not have a /Library/Tcl directory, nor does it have a /Library/Python directory.&nbsp; (Those two languages get installed as frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl and /Library/Java.</div><div><br></div><div>- Marc</div></div></div>
</div></blockquote></div>

</blockquote></div>
</div></blockquote></div>

</blockquote></div></div>
</blockquote></div>
</div></blockquote></body></html>

Re: [TCLCORE] More on TEA packages for macOS

[Marc C. <cul...@gm...>]

Of course we all expect wrong and missing information from AI
assistants, and expect different people to get different answers.  But I
think many people depend on those critters.  So it may be relevant to
report what google's "AI overview" said when I asked "What is the standard
location for a Tcl package on macOS?".

*AI Overview*
On macOS, Tcl packages can be found in several standard locations,
primarily within the system's framework directories
. The main directories where you'll find them are:

   - */Library/Frameworks*: This is the default location for third-party or
   built-from-source frameworks, including ActiveTcl releases.
   - */System/Library/Frameworks*: This directory contains Apple-supplied
   frameworks that come with macOS. *Note:* You should generally avoid
   modifying or deleting files in this directory.
   - *$HOME/Library/Frameworks*: You might also find Tcl and Tk frameworks
   in your user's Library directory.

- Marc

PS The stupidest part is warning people against modifying files in
/System/Library/Frameworks, as if that were even possible.

On Mon, Jun 16, 2025 at 1:36 PM Marc Culler <cul...@gm...> wrote:

> On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer <kw...@54...>
> wrote:
>
> You can pass —libdir as a flag to configure to set the install dir.
>>
>
> I guess you mean that you can do that when configuring an extension that
> you build locally?
>
>
>> I think the default directory is /usr/local if not otherwise defined.
>> Either way, I’m not a fan of putting external stuff in the frameworks.
>>
>
> I still don't know why you are not a fan.  However, the issue of what
> should be the default install location actually runs pretty deep at the
> moment, as I explain below.
>
> I recently committed a change to the tcllib repository to fix ticket [
> e5f3dfc055 <https://core.tcl-lang.org/tcllib/tktview/e5f3dfc055>], posted
> by Ashok a year ago, which was reporting that the Tcllib installer does not
> work "out of the box".  That means that the installer script would fail if
> you used its default install path, although you could edit the path if you
> happened to know where you wanted to install Tcllib. I think it is pretty
> clear that the default path for the Tcllib installer **should** be the
> "standard location" for Tcl packages, whatever that is.
>
> The reason that the installer script did not work was that it was choosing
> the zipfs as the install location on Windows and Linux, and the path
> /Library/Frameworks/Tk.framework/Versions on macOS.  It makes no sense to
> install a package in the zipfs and it also makes no sense to install a pure
> Tcl package in the Tk framework.  Moreover installing it in the Versions
> directory completely corrupts the structure of the Tk framework.
>
> The fix was to take the default install path to be the first item on the
> auto_path which does not begin with '//zipfs:'.  That works on all
> systems.  But it also means that on macOS the default location for
> installing Tcllib
> becomes /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.
>
> I am trying to argue that we need a *real* (documented) standard location
> and that we should actually think hard about what it should be.
>
> I am also trying to argue that we should make package installation cleaner
> and easier.
>
> Comment for Schelte:  It if were as easy to install a Tcl package as it is
> to install a Python or Ruby package, then it would be much easier to
> declare that useful additions should be extensions rather than part of the
> core.  But I claim that only an elite subset of Tcl/Tk experts actually
> know how to successfully install a Tcl/Tk package.  And I claim that there
> is currently no standard way to do that.
>
> - Marc
>
> PS I have learned a lot from wiki pages, but only when someone has
> provided me with a direct link to a specific wiki page.  I don't have much
> luck finding anyting useful on the wiki by starting at the top, and I
> suspect that I am not alone in that respect.  So I don't consider the wiki
> to be real documentation nor a place for a specification of something like
> what the default paths for installing Tcl packages should be on various
> operating systems.
>
>
>
>>
>> —Kevin
>>
>> On Jun 16, 2025, at 12:13 PM, Marc Culler <cul...@gm...> wrote:
>>
>> 
>> Hi Kevin,
>>
>> I am not sure that convention makes sense anymore, given that
>> /usr/bin/tclsh could not load any extension built for a currently supported
>> version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
>> is buried deep in the auto_path suggests that we are not really supporting
>> it now.  (I realize that different versions of Tcl could be supported in
>> subdirectories of /Library/Tcl, but I still think that, de facto, we are
>> not really supporting it.)  Supporting multiple versions is also a feature
>> of a framework.
>>
>> I think that being self-contained is a very good feature of a binary
>> distribution.  And I think it would be a good thing for Tcl/Tk to once
>> again be installable by downloading a single .pkg file and clicking on it.
>> And it would be good for such an installation to be able to add packages
>> without losing the property of being self-contained.  So I think we should
>> do what we can to facilitate moving in that direction.
>>
>> I note that this sort of installation scheme works well for Python, which
>> now embeds framework builds of Tcl and Tk within the Python.framework.
>> (Nested frameworks are allowed and encouraged by Apple, but not as
>> Resources.)
>>
>> - Marc
>>
>> On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
>> wrote:
>>
>>> Marc,
>>>
>>> It’s an older convention from the early days of macOS when Tcl/Tk was
>>> included and actively maintained in the system. The /Library/Tcl path was
>>> picked up by both the system installation and a locally installed build.
>>> Same principle applies to Perl, Python etc.
>>>
>>> The wiki FAQ I wrote also references this in build instructions for
>>> extensions:
>>>
>>> New Tcl/TkAqua FAQ
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
>>> wiki.tcl-lang.org
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
>>> <favicon.ico>
>>>
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>>>
>>> —Kevin
>>>
>>> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>>>
>>> 
>>> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
>>> wrote:
>>>
>>>> The canonical installation location for extension packages is
>>>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>>>
>>>
>>> Hi Kevin,
>>>
>>> Where do you find that canonical location specified?  And why shouldn't
>>> they go in the framework?
>>>
>>> Using that location seems to destroy one of the great advantages of
>>> using a framework - namely that all dependencies are contained in the
>>> framework.  Removing a framework should not involve hunting throughout the
>>> system for hidden dependencies which should be removed along with the
>>> framework because they become useless once the framework is gone.
>>>
>>> My system does not have a /Library/Tcl directory, nor does it have a
>>> /Library/Python directory.  (Those two languages get installed as
>>> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
>>> and /Library/Java.
>>>
>>> - Marc
>>>
>>>

Re: [TCLCORE] More on TEA packages for macOS

[Marc C. <cul...@gm...>]

On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer <kw...@54...>
wrote:

You can pass —libdir as a flag to configure to set the install dir.
>

I guess you mean that you can do that when configuring an extension that
you build locally?


> I think the default directory is /usr/local if not otherwise defined.
> Either way, I’m not a fan of putting external stuff in the frameworks.
>

I still don't know why you are not a fan.  However, the issue of what
should be the default install location actually runs pretty deep at the
moment, as I explain below.

I recently committed a change to the tcllib repository to fix ticket [
e5f3dfc055 <https://core.tcl-lang.org/tcllib/tktview/e5f3dfc055>], posted
by Ashok a year ago, which was reporting that the Tcllib installer does not
work "out of the box".  That means that the installer script would fail if
you used its default install path, although you could edit the path if you
happened to know where you wanted to install Tcllib. I think it is pretty
clear that the default path for the Tcllib installer **should** be the
"standard location" for Tcl packages, whatever that is.

The reason that the installer script did not work was that it was choosing
the zipfs as the install location on Windows and Linux, and the path
/Library/Frameworks/Tk.framework/Versions on macOS.  It makes no sense to
install a package in the zipfs and it also makes no sense to install a pure
Tcl package in the Tk framework.  Moreover installing it in the Versions
directory completely corrupts the structure of the Tk framework.

The fix was to take the default install path to be the first item on the
auto_path which does not begin with '//zipfs:'.  That works on all
systems.  But it also means that on macOS the default location for
installing Tcllib
becomes /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.

I am trying to argue that we need a *real* (documented) standard location
and that we should actually think hard about what it should be.

I am also trying to argue that we should make package installation cleaner
and easier.

Comment for Schelte:  It if were as easy to install a Tcl package as it is
to install a Python or Ruby package, then it would be much easier to
declare that useful additions should be extensions rather than part of the
core.  But I claim that only an elite subset of Tcl/Tk experts actually
know how to successfully install a Tcl/Tk package.  And I claim that there
is currently no standard way to do that.

- Marc

PS I have learned a lot from wiki pages, but only when someone has provided
me with a direct link to a specific wiki page.  I don't have much luck
finding anyting useful on the wiki by starting at the top, and I suspect
that I am not alone in that respect.  So I don't consider the wiki to be
real documentation nor a place for a specification of something like what
the default paths for installing Tcl packages should be on various
operating systems.



>
> —Kevin
>
> On Jun 16, 2025, at 12:13 PM, Marc Culler <cul...@gm...> wrote:
>
> 
> Hi Kevin,
>
> I am not sure that convention makes sense anymore, given that
> /usr/bin/tclsh could not load any extension built for a currently supported
> version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
> is buried deep in the auto_path suggests that we are not really supporting
> it now.  (I realize that different versions of Tcl could be supported in
> subdirectories of /Library/Tcl, but I still think that, de facto, we are
> not really supporting it.)  Supporting multiple versions is also a feature
> of a framework.
>
> I think that being self-contained is a very good feature of a binary
> distribution.  And I think it would be a good thing for Tcl/Tk to once
> again be installable by downloading a single .pkg file and clicking on it.
> And it would be good for such an installation to be able to add packages
> without losing the property of being self-contained.  So I think we should
> do what we can to facilitate moving in that direction.
>
> I note that this sort of installation scheme works well for Python, which
> now embeds framework builds of Tcl and Tk within the Python.framework.
> (Nested frameworks are allowed and encouraged by Apple, but not as
> Resources.)
>
> - Marc
>
> On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
> wrote:
>
>> Marc,
>>
>> It’s an older convention from the early days of macOS when Tcl/Tk was
>> included and actively maintained in the system. The /Library/Tcl path was
>> picked up by both the system installation and a locally installed build.
>> Same principle applies to Perl, Python etc.
>>
>> The wiki FAQ I wrote also references this in build instructions for
>> extensions:
>>
>> New Tcl/TkAqua FAQ
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
>> wiki.tcl-lang.org
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
>> <favicon.ico>
>>
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>>
>> —Kevin
>>
>> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>>
>> 
>> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
>> wrote:
>>
>>> The canonical installation location for extension packages is
>>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>>
>>
>> Hi Kevin,
>>
>> Where do you find that canonical location specified?  And why shouldn't
>> they go in the framework?
>>
>> Using that location seems to destroy one of the great advantages of using
>> a framework - namely that all dependencies are contained in the framework.
>> Removing a framework should not involve hunting throughout the system for
>> hidden dependencies which should be removed along with the framework
>> because they become useless once the framework is gone.
>>
>> My system does not have a /Library/Tcl directory, nor does it have a
>> /Library/Python directory.  (Those two languages get installed as
>> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
>> and /Library/Java.
>>
>> - Marc
>>
>>

Re: [TCLCORE] More on TEA packages for macOS

[Kevin W. <kw...@co...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.bh.d.sendibt3.com/tr/op/HlFSLVMbTqXRTQofhhbSwty-Og3w7cLdiFl7qfp-BtGffzKJPhI4m10-YVaPJJ37JwBri4UgTmidtKoqytW2fwDYdA45LpqQ9FtwjibW_m8q1CDYZjlred9Jvk99ZE3iDlr0WVOTOfIKHG9DkC8VW4KF-_s9CrXxrjzLO7HnbE_plsxN8hGusJwJat9M2uqruAI_98HFNUUYvHnAN-jYKzi7uF0pZOCj" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">You can pass —libdir as a flag to configure to set the install dir. I think the default directory is /usr/local if not otherwise defined. Either way, I’m not a fan of putting external stuff in the frameworks.</div><div dir="ltr"><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 12:13 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hi Kevin,</div><div><br></div><div>I am not sure that convention makes sense anymore, given that /usr/bin/tclsh could not load any extension built for a currently supported version of Tcl and that /usr/bin/wish crashes.&nbsp; Also the fact that the path is buried deep in the auto_path suggests that we are not really supporting it now.&nbsp; (I realize that different versions of Tcl could be supported in subdirectories of /Library/Tcl, but I still think that, de facto, we are not really supporting it.)&nbsp; Supporting multiple versions is also a feature of a framework.</div><div><br></div><div>I think that being self-contained is a very good feature of a binary distribution.&nbsp; And I think it would be a good thing for Tcl/Tk to once again be installable by downloading a single .pkg file and clicking on it.&nbsp; And it would be good for such an installation to be able to add packages without losing the property of being self-contained.&nbsp; So I think we should do what we can to facilitate moving in that direction.</div><div><br></div><div>I note that this sort of installation scheme works well for Python, which now embeds framework builds of Tcl and Tk within the Python.framework. (Nested frameworks are allowed and encouraged by Apple, but not as Resources.)</div><div><br></div><div>- Marc</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer &lt;<a href="mailto:kw...@54...">kw...@54...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/xa8VgqvLmExlO5-JONNIHss6ysMVM1eWnXcAINJD2YKpu3HSpkjmYTo6BPc3p47Jp3o0FkV7ox0n_26J6MLmQ1BF-uVPK7CuzoOy28ZD27hqPzXEeCKJLhsCWc_jSWg7UqDC7g2KH1RJ0P1qMo8V8168IiwHngtT1ZQzSrf1t_oRTkwID00Z8L1C4LW8vfg169wfw2zch1vn" data-unique-identifier=""><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">It’s an older convention from the early days of macOS when Tcl/Tk was included and actively maintained in the system. The /Library/Tcl path was picked up by both the system installation and a locally installed build. Same principle applies to Perl, Python etc. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">The wiki FAQ I wrote also references this in build instructions for extensions:&nbsp;</div><div dir="ltr"><br></div><div dir="ltr"><div style="display:block"><div style="display:inline-block" role="link"><a style="border-radius:10px;font-family:-apple-system,Helvetica,Arial,sans-serif;display:block;width:300px;overflow:hidden;text-decoration:none" rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA" dir="ltr" role="button" width="300" target="_blank"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:rgb(161,159,156);font-family:-apple-system,Helvetica,Arial,sans-serif" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td><table bgcolor="#A19F9C" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system,Helvetica,Arial,sans-serif;background-color:rgb(161,159,156)"><tbody><tr><td style="padding:8px 0px"><div style="max-width:100%;margin:0px 16px;overflow:hidden"><div style="font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgb(255,255,255)">New Tcl/TkAqua FAQ</font></a></div><div style="font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgba(235,235,245,0.6)">wiki.tcl-lang.org</font></a></div></div></td><td style="padding:6px 12px 6px 0px" width="30"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg" target="_blank"><div>&lt;favicon.ico&gt;</div></a></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 11:17 AM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/0rJGz8a-GZcLwfiuXHRXFKgO1by8S_61Z31B3A4zOaYK-SmjMHR1Lc_ly81ohzIKV3cnJCy7So6l1SZzBfCf2LmDUJuQiZPSMneed-7IuwcL3LrvQctBGg_SxXxyrhdr6eYRbbP1PoZwmHt9_zaOWXN1jz2hySSeoy6az3T32jEJAlkAE_SobNC09ixj9XqsvF309m8ylmXc" data-unique-identifier=""></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br></blockquote><div><br></div><div>Hi Kevin,</div><div><br></div><div>Where do you find that canonical location specified?&nbsp; And why shouldn't they go in the framework?</div><div>&nbsp;</div><div>Using that location seems to destroy one of the great advantages of using a framework - namely that all dependencies are contained in the framework.&nbsp; Removing a framework should not involve&nbsp;hunting throughout the system for hidden dependencies which should be removed along with the framework because they become useless once the framework is gone.</div><div><br></div><div>My system does not have a /Library/Tcl directory, nor does it have a /Library/Python directory.&nbsp; (Those two languages get installed as frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl and /Library/Java.</div><div><br></div><div>- Marc</div></div></div>
</div></blockquote></div>

</blockquote></div>
</div></blockquote></body></html>

Re: [TCLCORE] More on TEA packages for macOS

[Marc C. <cul...@gm...>]

Hi Kevin,

I am not sure that convention makes sense anymore, given that
/usr/bin/tclsh could not load any extension built for a currently supported
version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
is buried deep in the auto_path suggests that we are not really supporting
it now.  (I realize that different versions of Tcl could be supported in
subdirectories of /Library/Tcl, but I still think that, de facto, we are
not really supporting it.)  Supporting multiple versions is also a feature
of a framework.

I think that being self-contained is a very good feature of a binary
distribution.  And I think it would be a good thing for Tcl/Tk to once
again be installable by downloading a single .pkg file and clicking on it.
And it would be good for such an installation to be able to add packages
without losing the property of being self-contained.  So I think we should
do what we can to facilitate moving in that direction.

I note that this sort of installation scheme works well for Python, which
now embeds framework builds of Tcl and Tk within the Python.framework.
(Nested frameworks are allowed and encouraged by Apple, but not as
Resources.)

- Marc

On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
wrote:

> Marc,
>
> It’s an older convention from the early days of macOS when Tcl/Tk was
> included and actively maintained in the system. The /Library/Tcl path was
> picked up by both the system installation and a locally installed build.
> Same principle applies to Perl, Python etc.
>
> The wiki FAQ I wrote also references this in build instructions for
> extensions:
>
> New Tcl/TkAqua FAQ
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
> wiki.tcl-lang.org
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
> [image: favicon.ico]
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>
> —Kevin
>
> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>
> 
> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
> wrote:
>
>> The canonical installation location for extension packages is
>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>
>
> Hi Kevin,
>
> Where do you find that canonical location specified?  And why shouldn't
> they go in the framework?
>
> Using that location seems to destroy one of the great advantages of using
> a framework - namely that all dependencies are contained in the framework.
> Removing a framework should not involve hunting throughout the system for
> hidden dependencies which should be removed along with the framework
> because they become useless once the framework is gone.
>
> My system does not have a /Library/Tcl directory, nor does it have a
> /Library/Python directory.  (Those two languages get installed as
> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
> and /Library/Java.
>
> - Marc
>
>

Re: [TCLCORE] More on TEA packages for macOS

[Kevin W. <kw...@co...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/o_2sUSHBd-gHy8JA1Kzsnhx0AbIg5SfE0G1pE5nX-e7kaB8WWxqObkB7bSxhJ_wyWDY6HjtXPbgJA0gx4b9ViOvC5wpWG-cRP7bZpZ5fgGv452ZOQ7kbOQts7YG0nkUY6CP6uvLFIzWw-it-Rds5eCiqE4miNzO3oVNn-wYvlcLnP3hwOU-kfJQ5DnrYx4lYJc8w2oDvr-uq5z_Zwzo5AYd8_yRCjZzj" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">It’s an older convention from the early days of macOS when Tcl/Tk was included and actively maintained in the system. The /Library/Tcl path was picked up by both the system installation and a locally installed build. Same principle applies to Perl, Python etc. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">The wiki FAQ I wrote also references this in build instructions for extensions:&nbsp;</div><div dir="ltr"><br></div><div dir="ltr"><div style="display: block;" class=""><div style="-webkit-user-select: all; -webkit-user-drag: element; display: inline-block;" class="apple-rich-link" draggable="true" role="link" data-url="https://wiki.tcl-lang.org/page/New+Tcl%2FTkAqua+FAQ#6750c6b3086fb0aa6ce057ec7f101d06bd7ca242075c233f54c38591e1f3502d"><a style="border-radius:10px;font-family:-apple-system, Helvetica, Arial, sans-serif;display:block;-webkit-user-select:none;width:300px;user-select:none;-webkit-user-modify:read-only;user-modify:read-only;overflow:hidden;text-decoration:none;" class="lp-rich-link" rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/1ft9tLulb5VMtCeNNS7itGeuWDQ88w1U9HyIKwv6QLGHxhkh1SSJWLmzA-9QL1Ge0waMMMyFgjkTh2hLtTHRL1crs8ol9p1KotIsuH764BhCoW_WdoHlH3tBx1ySt51LM-vsGbfH5crtGhAhS4mgaUdtIGp_YFoMOo6-gW2E2On7gt6XDKwVQG6nw-xZLuOzMB6syLaGFI6CLDBJgdfs-Po43TxcOdnG0lzN8cYgDChapC53NeItngqIMUxSNCdlP-ovX2xiwiZD34xT11neJ63AzB94zjETLtSiM_RkZhakINoim991lVgcItXUYRnJWjOmIXDWgNECq3h7vx1e1YONHG6ywZkobaA-66mQNi5Lzm5L-fmPmYRYaQejnRAEzlpr4IINvHtnxecoopRrTcR8teG95g" dir="ltr" role="button" draggable="false" width="300"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:#A19F9C;font-family:-apple-system, Helvetica, Arial, sans-serif;" class="lp-rich-link-emailBaseTable" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td vertical-align="center"><table bgcolor="#A19F9C" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system, Helvetica, Arial, sans-serif;background-color:rgba(161, 159, 156, 1);-apple-color-filter:initial;" class="lp-rich-link-captionBar"><tbody><tr><td style="padding:8px 0px 8px 0px;" class="lp-rich-link-captionBar-textStackItem"><div style="max-width:100%;margin:0px 16px 0px 16px;overflow:hidden;" class="lp-rich-link-captionBar-textStack"><div style="word-wrap:break-word;font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-topCaption-leading"><a rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/g1LFEPqnCrFbQjRfcqRo6CIklb44r9JoBpYB3zUoHVZh81pSe28plhESI0S4YntjU8WehJheBEidnkSwSLije1wqvpX7KcGmtPCwU7c7ah3JnIoHmjHHFya_k3RGfZQQid-HFx632ZJ0tMzogAR5PdNbF__LuxYNpe5P_YApcM-vvUvO0jrUwVBVKNWEasFp3SqTPUNxMFxhzib2FPk5uN2xKHDMGSKS4vTrySUAT3ZB9-i-1uK8uFzU1DSkDyZ70akCy0dBSgcd7sXNXDO07J3s1-8bnZSfQGV6QvuqMGdtJ0vaG2op9xeANQjH8BMYm2FuWO3RSEkCLGaA_SHtzAZtDO3iZXf6tZvD2DwngdN9ab6X3r0r13ufQeBAFC-WNk48azyVDwAFct7i8JvR2ygVE1LGWA" style="text-decoration: none" draggable="false"><font color="#FFFFFF" style="color: rgba(255, 255, 255, 1);">New Tcl/TkAqua FAQ</font></a></div><div style="word-wrap:break-word;font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-bottomCaption-leading"><a rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/6D58jhCtbSO1_0QevgACukvYsjN4mKvqeaFEDuSpeJg7TwKoLGFjE7meklt66ocdg-m0xUiTrdH31Ki6UcXCaFssIEcFZaGHN2mLe42kqnpwaOlBKtkEmX71gvGYyrDxf2LAAtIy3LtrAZmLLvYViVzWirzq-YcM3X9-AJ_SmqFneLfm0tjR4x3umaj8xO1oQbuZ_6zhvuRqSVt4weRZ6Z_kOxETUatFZ96kdKJBHn6_Bn9RtpW21SCKyuZw8_NFFP2OVhW2JFz5TWU9FmyJJVkk-WQQ-H8lh6577gYeVgxGT1qEGX539cuRdwb3uGrWC0ZMIJwyFUIfEL48Qny8zY5kb3umGmCmXct1J1eVTJaKsDQ97QijA9Bw-1e0WiQoQ51SUzESY9GMYr6cCHeSYWyh16ZYSA" style="text-decoration: none" draggable="false"><font color="#FFFFFF" style="color: rgba(235, 235, 245, 0.6);">wiki.tcl-lang.org</font></a></div></div></td><td style="padding:6px 12px 6px 0px;" class="lp-rich-link-captionBar-rightIconItem" width="30"><a rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/Vn-GEWluY9N2aUfSyg1ERXYktdLcZonZ9RMKOKP25bKKIosnYrBolTLpPbr-MbqdrMRWjLh3BDRtBvPqcxX-2WhBhWBmNvWk2mUORPpKsrXoXybTuJo1dXX5CGEGo7QVToQcFowfTnS2a8xGqe0uBwoOFxLfNkxbAJjfliAsWDgcsUbk8pOUfYO3bR5X3aCuicHitsWVhtzW4YSjl9S0ifaXVCbzUfNhJoDOGvls1aH6_9qXGrfbekG-L_v9Zblwrgi62K7zsFBn4593LrUTKVL8Qkl2mDYNjiFp101SPvqWUZCnUJNxJnmFz5BfZLo1mj2L4G2hsODwRTfbbAqPIk7oR1oRmrKqAx0hDVIm9AFdmoLZJj-uXnT0oBrvZUsjmLAfLao4AIgAxowHZttGTerAmHnRmw" draggable="false"><img style="pointer-events:none !important;display:inline-block;width:30px;height:30px;border-radius:3px;" width="30" height="30" draggable="false" class="lp-rich-link-captionBar-rightIcon" alt="favicon.ico" src="cid:2A21B6D8-D465-4B05-8877-D255CF4233B4"></a></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 11:17 AM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer &lt;<a href="mailto:kw...@54...">kw...@54...</a>&gt; wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/0rJGz8a-GZcLwfiuXHRXFKgO1by8S_61Z31B3A4zOaYK-SmjMHR1Lc_ly81ohzIKV3cnJCy7So6l1SZzBfCf2LmDUJuQiZPSMneed-7IuwcL3LrvQctBGg_SxXxyrhdr6eYRbbP1PoZwmHt9_zaOWXN1jz2hySSeoy6az3T32jEJAlkAE_SobNC09ixj9XqsvF309m8ylmXc" data-unique-identifier=""></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br></blockquote><div><br></div><div>Hi Kevin,</div><div><br></div><div>Where do you find that canonical location specified?&nbsp; And why shouldn't they go in the framework?</div><div>&nbsp;</div><div>Using that location seems to destroy one of the great advantages of using a framework - namely that all dependencies are contained in the framework.&nbsp; Removing a framework should not involve&nbsp;hunting throughout the system for hidden dependencies which should be removed along with the framework because they become useless once the framework is gone.</div><div><br></div><div>My system does not have a /Library/Tcl directory, nor does it have a /Library/Python directory.&nbsp; (Those two languages get installed as frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl and /Library/Java.</div><div><br></div><div>- Marc</div></div></div>
</div></blockquote></body></html>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Marc C. <cul...@gm...>]

Hi Alexander,

I am not sure what you mean by v14.  Can you elaborate?

- Marc

On Mon, Jun 16, 2025 at 10:32 AM Alexander Schöpe <a.s...@gm...> wrote:

> I have also just tried this out. This is interesting in that it still ran
> under v14.
>
> > Am 16.06.2025 um 16:59 schrieb Marc Culler <cul...@gm...>:
> >
> > I decided to look at the crash report produced when you run
> /usr/bin/wish on macOS 15.  It turns out to add some interesting emphasis
> to what I was saying earlier about the structure of frameworks.
>
>
>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Alexander S. <a.s...@gm...>]

I have also just tried this out. This is interesting in that it still ran under v14.

> Am 16.06.2025 um 16:59 schrieb Marc Culler <cul...@gm...>:
> 
> I decided to look at the crash report produced when you run /usr/bin/wish on macOS 15.  It turns out to add some interesting emphasis to what I was saying earlier about the structure of frameworks.

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Alexander S. <a.s...@gm...>]

I think that's fine, because otherwise it's very complex to access this data.

> Am 16.06.2025 um 16:46 schrieb Marc Culler <cul...@gm...>:
> 
> In particular, the command ::tk::mac::GetAppPath has been part of the core for a long time.  I considered ::tk::mac::GetInfoAsJSON to be completely analogous to ::tk::mac::GetAppPath.
> 

Re: [TCLCORE] More on TEA packages for macOS

[Marc C. <cul...@gm...>]

Also, /Library/Tcl is pretty deep in the auto_path for tclsh9.0:

$ tclsh9.0
% puts $auto_path
/Library/Frameworks/Tcl.framework/Versions/9.0/Resources/Scripts
/Library/Frameworks/Tcl.framework/Versions/9.0/Resources /usr/local/lib
/Users/culler/Library/Tcl /Library/Tcl /Users/culler/Library/Frameworks
/Library/Frameworks /Library/Frameworks/Tk.framework/Versions

If it really were the canonical location, I would expect it to be the first
directory in the default auto_path.

- Marc

On Mon, Jun 16, 2025 at 10:16 AM Marc Culler <cul...@gm...> wrote:

> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
> wrote:
>
>> The canonical installation location for extension packages is
>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>
>
> Hi Kevin,
>
> Where do you find that canonical location specified?  And why shouldn't
> they go in the framework?
>
> Using that location seems to destroy one of the great advantages of using
> a framework - namely that all dependencies are contained in the framework.
> Removing a framework should not involve hunting throughout the system for
> hidden dependencies which should be removed along with the framework
> because they become useless once the framework is gone.
>
> My system does not have a /Library/Tcl directory, nor does it have a
> /Library/Python directory.  (Those two languages get installed as
> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
> and /Library/Java.
>
> - Marc
>

Re: [TCLCORE] More on TEA packages for macOS

[Marc C. <cul...@gm...>]

On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
wrote:

> The canonical installation location for extension packages is
> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>

Hi Kevin,

Where do you find that canonical location specified?  And why shouldn't
they go in the framework?

Using that location seems to destroy one of the great advantages of using a
framework - namely that all dependencies are contained in the framework.
Removing a framework should not involve hunting throughout the system for
hidden dependencies which should be removed along with the framework
because they become useless once the framework is gone.

My system does not have a /Library/Tcl directory, nor does it have a
/Library/Python directory.  (Those two languages get installed as
frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
and /Library/Java.

- Marc

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Marc C. <cul...@gm...>]

I decided to look at the crash report produced when you run /usr/bin/wish
on macOS 15.  It turns out to add some interesting emphasis to what I was
saying earlier about the structure of frameworks.  The crash report says:

Exception Type:  EXC_CRASH (SIGKILL (Code Signature Invalid))
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: CODESIGNING 4 Launch Constraint Violation

Note that /usr/bin/wish is a shell script which calls the main executable
in Apple's Wish.app.  So this is really an issue with signing a macOS app.

Codesigning and, to a lesser extent, notarization really have become huge
considerations for macOS developers.  And Apple can't even get it right on
their own code, although I would expect them to try to blame it on Tcl.

- Marc

On Mon, Jun 16, 2025 at 9:46 AM Marc Culler <cul...@gm...> wrote:

> On Mon, Jun 16, 2025 at 5:26 AM Kevin Walzer <kw...@co...> wrote:
>
>> For better or worse, the Mac does have a large batch of platform specific
>> bits that are included in the tk::mac namespace but are core. There isn’t a
>> tk::win namespace or tk::unix. Not sure how that evolved, but it’s there.
>
>
> In particular, the command *::tk::mac::GetAppPath*
> <https://www.tcl-lang.org/man/tcl9.0/TkCmd/tk_mac.html#M18> has been part
> of the core for a long time.  I considered ::tk::mac::GetInfoAsJSON to be
> completely analogous to ::tk::mac::GetAppPath.
>
> I can only speculate about the history of ::tk::mac, but my speculation
> would be that its existence is related to the fact that Apple Inc. is
> listed as a copyright holder for most of the files in the macosx
> directory.  Of course that does not explain the lack of a ::tk::sun
> namespace, but my guess is that ::tk::mac appeared when Apple was actually
> involved with the Tcl project.
>
> What a different time that must have been!
>
> Nowadays Apple distributes a program called /usr/bin/wish with their macOS
> 15 operating system which instantly segfaults if you attempt to run it.
> They can't even be bothered to fix the segfault by removing Tcl from their
> OS, which would at least avoid all of the nightmares that can happen when
> the Tcl build system finds /System/Library/Frameworks/Tcl.framework.
>
> - Marc
>
>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Marc C. <cul...@gm...>]

On Mon, Jun 16, 2025 at 5:26 AM Kevin Walzer <kw...@co...> wrote:

> For better or worse, the Mac does have a large batch of platform specific
> bits that are included in the tk::mac namespace but are core. There isn’t a
> tk::win namespace or tk::unix. Not sure how that evolved, but it’s there.


In particular, the command *::tk::mac::GetAppPath*
<https://www.tcl-lang.org/man/tcl9.0/TkCmd/tk_mac.html#M18> has been part
of the core for a long time.  I considered ::tk::mac::GetInfoAsJSON to be
completely analogous to ::tk::mac::GetAppPath.

I can only speculate about the history of ::tk::mac, but my speculation
would be that its existence is related to the fact that Apple Inc. is
listed as a copyright holder for most of the files in the macosx
directory.  Of course that does not explain the lack of a ::tk::sun
namespace, but my guess is that ::tk::mac appeared when Apple was actually
involved with the Tcl project.

What a different time that must have been!

Nowadays Apple distributes a program called /usr/bin/wish with their macOS
15 operating system which instantly segfaults if you attempt to run it.
They can't even be bothered to fix the segfault by removing Tcl from their
OS, which would at least avoid all of the nightmares that can happen when
the Tcl build system finds /System/Library/Frameworks/Tcl.framework.

- Marc

Re: [TCLCORE] More on TEA packages for macOS

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/sLNRu7ZQMGhr6nitiyonRjn0wAt1e-inYA5jI3dJB1eQYlaklfv7x0wPvAOd2wnWcBhqs-gpPSdq8N3103fO8bCbABW0m941SOSl9OcDGzzVNrskPmmgJsXi4So-_gzDM_q-m5VTstF73ocob1Ak8DFJwWkztOEVftWnk3_YRn0tA5imhUOrQSVt4mww8frxFMO5JFHm7NQjxUiWLUqk4PawwZnRxCNY" style="mso-hide:all"/></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br/><br/>> On Jun 16, 2025, at 10:11 AM, Marc Culler <cul...@gm...> wrote:<br/>> <br/>> <br/>> My second question (which is more of a topic than a question, and is really a request for comments) is: where should Tcl and Tk extensions be installed in macOS?<br/>> <br/>> I have a proposal, and it is different from the current scheme.<br/>> <br/>> First some background ...<br/>> <br/>> There are two ways to install Tcl on macOS:<br/>> - a traditional unix "prefix" installation, usually with prefix /usr/local<br/>> - a "framework" install, usually in /Library/Frameworks<br/>> <br/>> I am talking about the "framework" install only.  Note that this is the most common way of installing Tcl and Tk on macOS, and is also how Active State used to distribute Tcl and Tk.<br/>> <br/>> It turns out that there are two critical, but non-obvious, components related to frameworks: codesigning and notarization.  It is now required on Apple Silicon that every binary, i.e. executable or shared library, be signed (although ad-hoc signatures are allowed).  If an executable is not signed it is instantly killed by Apple's gatekeeper.  Distributing non-notarized macOS apps outside of the app store is possible but presents unpleasant UX which is a barrier to usefulness.  Ad-hoc signatures are not allowed for notarized apps, and notarization is required for the app store.<br/>> <br/>> Codesigning and notarization are related to frameworks because Apple has a specification for the structure of a framework, albeit a very loose one, which is enforced primarily by threat.  The threat is that if you do not follow the spec, vague as it may be, you can expect issues with codesigning and notarization.<br/>> <br/>> Next, about TEA packages:<br/>> <br/>> Currently the standard location for a Tcl or Tk extension package is:<br/>>   /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts<br/>> or<br/>>   /Library/Frameworks/Tk.framework/Versions/X.Y/Resources/Scripts<br/>> <br/>> I don't think that is such a good choice.<br/>> <br/>> First, at the most basic level, binary packages are not scripts.  Even a pure Tcl package is more than a script.  A tcl module could be viewed as a script,<br/>> but, in my opinion, it would be better to call it what it is, a module.<br/>> <br/>> Putting shared libraries into the Resources directory, even within a package subdirectory, is problematic with respect to Apple's framework "spec".<br/>> Apple says that the Resources directory should contain all of the resources, where "a resource is anything which is not code".  They then go on to try to explain what code is.  Code is NOT a file which can be executed.  In particular a Tcl script (or a Python script, to use Apple's example) is not code even though it can be executed.  If you work your way through their tortured explanation, what you eventually learn is that the definition of "code" depends on codesigning.<br/>> <br/>> A file is "code" if it has a code signature embedded in the file.  (A text file can be signed, but the signature gets embedded in the "extended attributes" which are not preserved by most archiving formats, including zip and tar.  (They are preserved by .dmg).  A directory is "code" if it has a standard location for a code signature file.  So apps and frameworks are code.<br/>> <br/>> This means that we are currently breaking the so-called rules by putting binary extensions into the Resources directory, since such an extension contains a .dylib file, which can (and must, on Arm hardware) have an embedded signature.  Also, a package is not a "Script".  However a package would be a resource, if it did not contain a shared library.<br/>> <br/>> The format of the pkgIndex.tcl file does not require that the shared library be a sibling of the pkgIndex.tcl.  Any location can be specified, relative to the directory containing the pkgIndex.tcl file.<br/>> <br/>> So here is my proposal (where Z is Tcl or Tk, and where frameworks can either be installed in /Library/Frameworks or somewhere else):<br/>> <br/>> 1. Packages should be installed in<br/>>   /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Packages<br/>> <br/>> 2. Modules should be installed in<br/>>   /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Modules<br/>> <br/>> 3. BUT, for binary extensions, the .dylib file should not be installed in<br/>> Resources.  Instead it should be installed in<br/>>   /path/to/Frameworks/Z.framework/Versions/X.Y/dylibs<br/>> and the load command in the pkgIndex.tcl file should look like:<br/>>     load [file join $dir .. .. dylibs libtcl9blahblah.dylib]<br/>> <br/>> I would welcome any comments<br/>> <br/>> - Marc<br/>> <br/>> <br/>> <br/>> <br/>> <br/>> <br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>

[TCLCORE] More on TEA packages for macOS

[Marc C. <cul...@gm...>]

My second question (which is more of a topic than a question, and is really
a request for comments) is: where should Tcl and Tk extensions be installed
in macOS?

I have a proposal, and it is different from the current scheme.

First some background ...

There are two ways to install Tcl on macOS:
- a traditional unix "prefix" installation, usually with prefix /usr/local
- a "framework" install, usually in /Library/Frameworks

I am talking about the "framework" install only.  Note that this is the
most common way of installing Tcl and Tk on macOS, and is also how Active
State used to distribute Tcl and Tk.

It turns out that there are two critical, but non-obvious, components
related to frameworks: codesigning and notarization.  It is now required on
Apple Silicon that every binary, i.e. executable or shared library, be
signed (although ad-hoc signatures are allowed).  If an executable is not
signed it is instantly killed by Apple's gatekeeper.  Distributing
non-notarized macOS apps outside of the app store is possible but presents
unpleasant UX which is a barrier to usefulness.  Ad-hoc signatures are not
allowed for notarized apps, and notarization is required for the app store.

Codesigning and notarization are related to frameworks because Apple has a
specification for the structure of a framework, albeit a very loose one,
which is enforced primarily by threat.  The threat is that if you do not
follow the spec, vague as it may be, you can expect issues with
codesigning and notarization.

Next, about TEA packages:

Currently the standard location for a Tcl or Tk extension package is:
  /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts
or
  /Library/Frameworks/Tk.framework/Versions/X.Y/Resources/Scripts

I don't think that is such a good choice.

First, at the most basic level, binary packages are not scripts.  Even a
pure Tcl package is more than a script.  A tcl module could be viewed as a
script,
but, in my opinion, it would be better to call it what it is, a module.

Putting shared libraries into the Resources directory, even within a
package subdirectory, is problematic with respect to Apple's framework
"spec".
Apple says that the Resources directory should contain all of the
resources, where "a resource is anything which is not code".  They then go
on to try to explain what code is.  Code is NOT a file which can be
executed.  In particular a Tcl script (or a Python script, to use Apple's
example) is not code even though it can be executed.  If you work your way
through their tortured explanation, what you eventually learn is that the
definition of "code" depends on codesigning.

A file is "code" if it has a code signature embedded in the file.  (A text
file can be signed, but the signature gets embedded in the "extended
attributes" which are not preserved by most archiving formats, including
zip and tar.  (They are preserved by .dmg).  A directory is "code" if it
has a standard location for a code signature file.  So apps and frameworks
are code.

This means that we are currently breaking the so-called rules by putting
binary extensions into the Resources directory, since such an extension
contains a .dylib file, which can (and must, on Arm hardware) have an
embedded signature.  Also, a package is not a "Script".  However a package
would be a resource, if it did not contain a shared library.

The format of the pkgIndex.tcl file does not require that the shared
library be a sibling of the pkgIndex.tcl.  Any location can be specified,
relative to the directory containing the pkgIndex.tcl file.

So here is my proposal (where Z is Tcl or Tk, and where frameworks can
either be installed in /Library/Frameworks or somewhere else):

1. Packages should be installed in
  /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Packages

2. Modules should be installed in
  /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Modules

3. BUT, for binary extensions, the .dylib file should not be installed in
Resources.  Instead it should be installed in
  /path/to/Frameworks/Z.framework/Versions/X.Y/dylibs
and the load command in the pkgIndex.tcl file should look like:
    load [file join $dir .. .. dylibs libtcl9blahblah.dylib]

I would welcome any comments

- Marc

[TCLCORE] Report of TCL/Tk biweekly telco on 2nd of June, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

[Harald O. <har...@el...>]

Dear Tcl/Tk team,

thank you for your participation at the telco.

An old agenda was followed. Sorry.
But it was a great meeting !

Here is my report:
1) Release items for TCL/Tk 9.0.2
Branch will start today.
Testing is clean.
RC0 is ready soon.

Ashok has some bug-fixes, which may only go to 9.1.
Only important on heavy load, use after free.
Not for 9.0.2, as there are risks.

lseq corner cases will probably also not in 9.0.2, currently only in 
9.1. Donal Fellows has taken over with new test cases.

2) Release items for Tcl/Tk 9.1.0a0
www.tcl-lang.org
-> new page needed for 9.1 as this one:
https://www.tcl-lang.org/software/tcltk/9.0.html
-> Copy the .tml template file.
-> include input from "changes.md".

3) TIP 723: monotonic clock: is it a bug? Platform solutions
New specification, no implementation jet, is for later.

4) TIP 712: positive options to the subst command
TIP merged, all ok.

5) Reinhards new socket stuff
May start as an extension and then go to the core.

QUICK WIP by Schelte.
Link to new socket stuff is not clear.

6) tk print enhancements
Great part of 9.0.2 - thank you.
Very careful work - test cases present, great work.

7) TIP 725: JSON PLIST access
Ok to have platform specific things as long as they are commonly useful.

It would be great if JSON data would be natively supported by 9.1.
We need more people in the core to make dreams reality.

8) TIP 720: TCL compiler reform
Great work, try, lseq,...

We need duplicate the test cases for compiled, semi-compiled and not 
compiled for each newly compiled command: try, lseq, ...

9) Documentation
Great work, thanks Torsten!
Back-porting of corrections would be great.

Troff-file corrections may be merged before md merge, but no hurry.

10) Bundled packages

- SQLite: February Version will be distributed. Current update from 
SQLite is pending, but not in 9.0.2.
- TDBC: there are changes, but no reason to hurry for 9.0.2.

Massimo, what about a release of TDBC?

10) Orphan packages repository

tkpath added from Steve Shaw, which is the latested.
Others are in Androwish and from René and BAWT.
Contributions welcome !

11) Conference status
Deadline soon.

12) Init functions.
I have to add something to the Init on Windows.
Which are the calls for Init?
Tcl_FindExecutable(NULL)
Once per process should be sufficient.
Tcl_CreateInterp()

13) tclconfig project
The project has a couple of changes.
This would change all bundled packages.

14) TIP 649: List API TIP
Vote warning soon.
Nobody commented the question about reference count details.
Input welcome!

Other meetings:
30th of June 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi

Thank you all,
Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/CVHAVkZ8imDqLveq37xtgGUOATl88X1Lf3eTViPQa9GfENYvVdVb_QKtLYRUpem-R3eI_40iTaR3vH9SCsehVuPiHFf7gdUOv-kY3QgjFmQ9RvbsuOq2z60L-YYA9V1Bx0pPOP9iBGJcr7AAjtN-3iydAeGMFt102Q6Kf74v4bnxQlL3JWd_n06FW3fVOHv6iNHDgDlt2_EQsuYibM1MrW7tcipi" style="mso-hide:all"/></div>For better or worse, the Mac does have a large batch of platform specific bits that are included in the tk::mac namespace but are core. There isn’t a tk::win namespace or tk::unix. Not sure how that evolved, but it’s there. <br/><br/>> On Jun 16, 2025, at 5:30 AM, Schelte Bron <tc...@tc...> wrote:<br/>> <br/>> Harald,<br/>> <br/>> There is no issue for me. I think it's a reasonable policy to avoid unnecessary core bloat. So I generally tend to make my contributions as extensions, not TIPs. That has the added bonus that the new features can already be used with existing Tcl/Tk versions.<br/>> <br/>> GetInfoAsJSON looks to me like something that might also better be done as an extension. Not least because the extent of its usefulness is quite questionable to me. I don't have the impression this is a feature that has been requested frequently. To my knowledge only one person asked about it and Marc just took up the challenge. It seems to me more like a weekend fun project than something that definitely needs to be present in the core.<br/>> <br/>> But that's just my impression. I don't have a vote, so by all means feel free to ignore my opinion.<br/>> <br/>> <br/>> Schelte.<br/>> <br/>> <br/>>> On 16/06/2025 10:44, Harald Oehlmann wrote:<br/>>> Schelte,<br/>>> if you have time today 2pm European time for the biweekly telco, we may discuss your case. Perhaps, you may distribute background information prior to the meeting.<br/>>> Thanks for all,<br/>>> Harald<br/>>>> Am 16.06.2025 um 10:29 schrieb Harald Oehlmann:<br/>>>> Am 16.06.2025 um 09:54 schrieb Schelte Bron:<br/>>>>> I'm a bit puzzled why this is considered for inclusion into the core. When a linux-only feature was suggested in the past, the feedback was that it didn't need to be in the core, it could be done as an extension. Sure, fair enough. But why doesn't the same reasoning apply to this feature? Is there a valid reason this cannot be done as an extension? Or is it just a double standard: Windows-only and Mac- only features can be added to the core, while unix-only features should be done as an extension?<br/>>>>> <br/>>>>> <br/>>>>> Schelte.<br/>>>> Schelte,<br/>>>> <br/>>>> thanks for the comment.<br/>>>> I am sorry that you got a negative answer on a Linux-only core extension. It was hopefully not me, as I normally try to get anything in what has a use-case and a supporter.<br/>>>> <br/>>>> I am personally against not including useful features to the core.<br/>>>> And if they are platform dependent, than this is as it is.<br/>>>> I am personally use-case driven.<br/>>>> So here, is a use-case.<br/>>>> <br/>>>> In addition, someone should do the work. The MAC platform is the most advanced platform with most platform specific features due to the fact, that Mark cares.<br/>>>> On Windows, we have no care-person for Tk (on Tcl, we have Ashok).<br/>>>> Linux/Unix is to my perception very difficult, as the platform has many variants and we have only little supporters.<br/>>>> When I asked about the monotonic patch on Linux, only a Windows only guy answered. It was impossible to get a review on Linux. This disqualified the patch on Linux.<br/>>>> <br/>>>> On Windows, we have most annoying bugs since 20 years in Tk and nobody cares. We all would love to have someone like Mark !<br/>>>> <br/>>>> I hope, we will solve the issue for you !<br/>>>> <br/>>>> Take care,<br/>>>> Harald<br/>> <br/>> <br/>> <br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Schelte B. <tc...@tc...>]

Harald,

There is no issue for me. I think it's a reasonable policy to avoid 
unnecessary core bloat. So I generally tend to make my contributions as 
extensions, not TIPs. That has the added bonus that the new features can 
already be used with existing Tcl/Tk versions.

GetInfoAsJSON looks to me like something that might also better be done 
as an extension. Not least because the extent of its usefulness is quite 
questionable to me. I don't have the impression this is a feature that 
has been requested frequently. To my knowledge only one person asked 
about it and Marc just took up the challenge. It seems to me more like a 
weekend fun project than something that definitely needs to be present 
in the core.

But that's just my impression. I don't have a vote, so by all means feel 
free to ignore my opinion.


Schelte.


On 16/06/2025 10:44, Harald Oehlmann wrote:
> Schelte,
> if you have time today 2pm European time for the biweekly telco, we may 
> discuss your case. Perhaps, you may distribute background information 
> prior to the meeting.
> 
> Thanks for all,
> Harald
> 
> Am 16.06.2025 um 10:29 schrieb Harald Oehlmann:
>> Am 16.06.2025 um 09:54 schrieb Schelte Bron:
>>> I'm a bit puzzled why this is considered for inclusion into the core. 
>>> When a linux-only feature was suggested in the past, the feedback was 
>>> that it didn't need to be in the core, it could be done as an 
>>> extension. Sure, fair enough. But why doesn't the same reasoning 
>>> apply to this feature? Is there a valid reason this cannot be done as 
>>> an extension? Or is it just a double standard: Windows-only and Mac- 
>>> only features can be added to the core, while unix-only features 
>>> should be done as an extension?
>>>
>>>
>>> Schelte.
>> Schelte,
>>
>> thanks for the comment.
>> I am sorry that you got a negative answer on a Linux-only core 
>> extension. It was hopefully not me, as I normally try to get anything 
>> in what has a use-case and a supporter.
>>
>> I am personally against not including useful features to the core.
>> And if they are platform dependent, than this is as it is.
>> I am personally use-case driven.
>> So here, is a use-case.
>>
>> In addition, someone should do the work. The MAC platform is the most 
>> advanced platform with most platform specific features due to the 
>> fact, that Mark cares.
>> On Windows, we have no care-person for Tk (on Tcl, we have Ashok).
>> Linux/Unix is to my perception very difficult, as the platform has 
>> many variants and we have only little supporters.
>> When I asked about the monotonic patch on Linux, only a Windows only 
>> guy answered. It was impossible to get a review on Linux. This 
>> disqualified the patch on Linux.
>>
>> On Windows, we have most annoying bugs since 20 years in Tk and nobody 
>> cares. We all would love to have someone like Mark !
>>
>> I hope, we will solve the issue for you !
>>
>> Take care,
>> Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Harald O. <har...@el...>]

Schelte,
if you have time today 2pm European time for the biweekly telco, we may 
discuss your case. Perhaps, you may distribute background information 
prior to the meeting.

Thanks for all,
Harald

Am 16.06.2025 um 10:29 schrieb Harald Oehlmann:
> Am 16.06.2025 um 09:54 schrieb Schelte Bron:
>> I'm a bit puzzled why this is considered for inclusion into the core. 
>> When a linux-only feature was suggested in the past, the feedback was 
>> that it didn't need to be in the core, it could be done as an 
>> extension. Sure, fair enough. But why doesn't the same reasoning apply 
>> to this feature? Is there a valid reason this cannot be done as an 
>> extension? Or is it just a double standard: Windows-only and Mac-only 
>> features can be added to the core, while unix-only features should be 
>> done as an extension?
>>
>>
>> Schelte.
> Schelte,
> 
> thanks for the comment.
> I am sorry that you got a negative answer on a Linux-only core 
> extension. It was hopefully not me, as I normally try to get anything in 
> what has a use-case and a supporter.
> 
> I am personally against not including useful features to the core.
> And if they are platform dependent, than this is as it is.
> I am personally use-case driven.
> So here, is a use-case.
> 
> In addition, someone should do the work. The MAC platform is the most 
> advanced platform with most platform specific features due to the fact, 
> that Mark cares.
> On Windows, we have no care-person for Tk (on Tcl, we have Ashok).
> Linux/Unix is to my perception very difficult, as the platform has many 
> variants and we have only little supporters.
> When I asked about the monotonic patch on Linux, only a Windows only guy 
> answered. It was impossible to get a review on Linux. This disqualified 
> the patch on Linux.
> 
> On Windows, we have most annoying bugs since 20 years in Tk and nobody 
> cares. We all would love to have someone like Mark !
> 
> I hope, we will solve the issue for you !
> 
> Take care,
> Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Harald O. <har...@el...>]

Am 16.06.2025 um 09:54 schrieb Schelte Bron:
> I'm a bit puzzled why this is considered for inclusion into the core. 
> When a linux-only feature was suggested in the past, the feedback was 
> that it didn't need to be in the core, it could be done as an extension. 
> Sure, fair enough. But why doesn't the same reasoning apply to this 
> feature? Is there a valid reason this cannot be done as an extension? Or 
> is it just a double standard: Windows-only and Mac-only features can be 
> added to the core, while unix-only features should be done as an extension?
> 
> 
> Schelte.
Schelte,

thanks for the comment.
I am sorry that you got a negative answer on a Linux-only core 
extension. It was hopefully not me, as I normally try to get anything in 
what has a use-case and a supporter.

I am personally against not including useful features to the core.
And if they are platform dependent, than this is as it is.
I am personally use-case driven.
So here, is a use-case.

In addition, someone should do the work. The MAC platform is the most 
advanced platform with most platform specific features due to the fact, 
that Mark cares.
On Windows, we have no care-person for Tk (on Tcl, we have Ashok).
Linux/Unix is to my perception very difficult, as the platform has many 
variants and we have only little supporters.
When I asked about the monotonic patch on Linux, only a Windows only guy 
answered. It was impossible to get a review on Linux. This disqualified 
the patch on Linux.

On Windows, we have most annoying bugs since 20 years in Tk and nobody 
cares. We all would love to have someone like Mark !

I hope, we will solve the issue for you !

Take care,
Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

[Schelte B. <tc...@tc...>]

I'm a bit puzzled why this is considered for inclusion into the core. 
When a linux-only feature was suggested in the past, the feedback was 
that it didn't need to be in the core, it could be done as an extension. 
Sure, fair enough. But why doesn't the same reasoning apply to this 
feature? Is there a valid reason this cannot be done as an extension? Or 
is it just a double standard: Windows-only and Mac-only features can be 
added to the core, while unix-only features should be done as an extension?


Schelte.


On 15/06/2025 17:01, Marc Culler wrote:
> This TIP was discussed quite a bit on this list, and the discussion now 
> seems to have run its course without any objections having been raised.  
> So I intend to call for a vote in a day or two.
> 
> - Marc

Re: [TCLCORE] TEA packages on macOS

[Schelte B. <tc...@tc...>]

On 15/06/2025 21:55, Marc Culler wrote:
> Well, yeah.  If it had been documented then I might have avoided quite a 
> few painful hours (since every interaction with autoconf is painful) of 
> hacking my own tcl.m4.  Knowing about this will be extremely useful to me.

Next to the documentation, the wiki is a useful source of information:
https://wiki.tcl-lang.org/page/SampleExtension


Schelte.