attached is an improved version.
Changes:
- Clean function: "mac-ports-bundle.sh clean"
- installs into /opt/local/libexec/macports
- use sha checksum to validate curled tar files
-gustaf
Am 14.07.13 06:11, schrieb Ryan Schmidt:
On Jul 13, 2013, at 08:37, Lawrence Velázquez wrote:
On Jul 13,
On Jul 13, 2013, at 12:11, Gustaf Neumann wrote:
> Am 13.07.13 15:53, schrieb Lawrence Velázquez:
>> Bootstrapping from source would be weird, for one. I suppose we'd bundle Tcl
>> with the source, install using that one, install the Tcl port, and reinstall
>> off of the port? It sounds gross, bu
On Jul 13, 2013, at 08:37, Lawrence Velázquez wrote:
> On Jul 13, 2013, at 8:25 AM, Gustaf Neumann wrote:
>
>> The macports private version is installed under
>> /opt/local/share/macports/{bin|lib|include|man},
>> so one can use this tclsh via preplacing
>> /usr/bin/tclsh in /opt/local/bin/port
On Jul 13, 2013, at 2:31 PM, Jordan K. Hubbard wrote:
> On Jul 13, 2013, at 6:53 AM, Lawrence Velázquez wrote:
>
>> Bootstrapping from source would be weird, for one. I suppose we'd bundle Tcl
>> with the source, install using that one, install the Tcl port, and reinstall
>> off of the port?
oving tcl would then
require "sudo port -f uninstall tcl", and that's as unsupported as "sudo rm -fR
/opt/local/libexec/macports/tcl" would be.
> - if someone installs a broken tcl-port, everything will be broken.
If MacPorts' build system happens to pull down a
Am 13.07.13 15:53, schrieb Lawrence Velázquez:
Bootstrapping from source would be weird, for one. I suppose we'd
bundle Tcl with the source, install using that one, install the Tcl
port, and reinstall off of the port? It sounds gross, but it would
only have to happen for the initial install.
n
On Jul 11, 2013, at 3:25 AM, Ryan Schmidt wrote:
> I suppose so. But there's still the idea of self-hosting MacPorts, where
> MacPorts would come with the MacPorts port pre-installed and the selfupdate
> mechanism would be just a thin shim around updating the MacPorts port:
>
> https://trac.ma
On Jul 13, 2013, at 8:25 AM, Gustaf Neumann wrote:
> The macports private version is installed under
> /opt/local/share/macports/{bin|lib|include|man},
> so one can use this tclsh via preplacing
> /usr/bin/tclsh in /opt/local/bin/port by
> /opt/local/share/macports/bin/tclsh8.5
/opt/local/share/
On Sat, Jul 13, 2013 at 02:25:27PM +0200, Gustaf Neumann wrote:
> Attached is a script that does the full cycle, albeit for tcl 8.5. and
> tcllib 1.15;
Thank you, that's very helpful. I'll see if I can get this into base (or
at least a branch) next week.
> so one can use this tclsh via preplacing
Am 10.07.13 00:01, schrieb Clemens Lang:
Of course, if you want to come up with a script that will build Tcl 8.6
somwhere in a private prefix with --enable-threads and the thread
module, be my guest :)
Attached is a script that does the full cycle, albeit for tcl 8.5.
and tcllib 1.15;
This wou
Oh, I filed reports with apple. In fact, for anyone with troubles on any
OSX, http://bugreporter.apple.com is your best friend. Use it.
It just made me think of the idea of reducing dependencies. Especially if,
for example, we want to move to Tcl 8.X or a new cURL/Subversion, before
Apple does.
I
On Jul 11, 2013, at 06:01, Rainer Müller wrote:
> On 2013-07-07 20:51, Mark Anderson wrote:
>> Mainly because of my troubles with a certain OSX that is not to be named
>> or the fiery NDA demons will smite me.
>
> There are ways to communicate such problems to Apple for those who have
> such troub
On 2013-07-07 20:51, Mark Anderson wrote:
> Mainly because of my troubles with a certain OSX that is not to be named
> or the fiery NDA demons will smite me.
There are ways to communicate such problems to Apple for those who have
such troubles. The common measure seems to be the more reports they
On Jul 11, 2013, at 01:14, Clemens Lang wrote:
> On Wed, Jul 10, 2013 at 09:54:30PM -0500, Ryan Schmidt wrote:
>> There seem to be two ideas going on here:
>>
>> 1. ship a known good version of Tcl with MacPorts so that we avoid
>> bugs in versions of Tcl on specific versions of OS X
>> 2. use Tc
On Wed, Jul 10, 2013 at 09:54:30PM -0500, Ryan Schmidt wrote:
> There seem to be two ideas going on here:
>
> 1. ship a known good version of Tcl with MacPorts so that we avoid
> bugs in versions of Tcl on specific versions of OS X
> 2. use Tcl 8.6 so that we can simplify some of MacPorts base
On Jul 10, 2013, at 04:26, Gustaf Neumann wrote:
> - since the try-usage in macports is limited, one should be
> able to modify the mac-ports-included try implementation to
> handle instead of "catch" the "on" variant from TIP#329.
> That would at least ease a migration phase.
There seem to b
Am 10.07.13 10:41, schrieb Rainer Müller:
In the same way we currently have a local implementation of try based
upon TIP #89, we could make it compatible with TIP #329/Tcl 8.6 instead.
This could mean just importing the one from Tcllib (haven't checked its
license) and make it work on Tcl 8.4. I
On Wed, Jul 10, 2013 at 10:41:35AM +0200, Rainer Müller wrote:
> In the same way we currently have a local implementation of try based
> upon TIP #89, we could make it compatible with TIP #329/Tcl 8.6
> instead.
The sentence
"It supercedes TIP #89 by providing support for the error options
dic
On 2013-07-10 00:01, Clemens Lang wrote:
> On Tue, Jul 09, 2013 at 07:21:41PM +0200, Gustaf Neumann wrote:
>> It certainly needs an update in the macports base, but i would not
>> expect this to be painful. Let me know, if i can help.
>
> At the moment there's not much we can do, before we have a
On Tue, Jul 09, 2013 at 07:21:41PM +0200, Gustaf Neumann wrote:
> It certainly needs an update in the macports base, but i would not
> expect this to be painful. Let me know, if i can help.
At the moment there's not much we can do, before we have a working
bootstrap mechanism for Tcl 8.6 (or rathe
Am 09.07.13 17:56, schrieb Clemens Lang:
Unfortunately the try implemented in tcl 8.6 seems to be TIP #329 [1].
oops, you are right, forgot that (the discussion was in 2008).
At a glace, it seems MacPorts' try indeed conforms to TIP #89, but TIP
#329 no longer provides the "catch" block availab
On Tue, Jul 09, 2013 at 05:25:19PM +0200, Gustaf Neumann wrote:
> The command "try" is new built-in tcl 8.6.
Unfortunately the try implemented in tcl 8.6 seems to be TIP #329 [1].
At a glace, it seems MacPorts' try indeed conforms to TIP #89, but TIP
#329 no longer provides the "catch" block avail
The command "try" is new built-in tcl 8.6. Since the implementation of
proc "try" in macports_util.tcl says, it is compatible with Tcl TIP #89,
lets hope that the usage pattern in of "try" in macports are compatible
with TIP #89, and one can use the built-in "try" instead of the proc -
at least
Hi,
On Mon, Jul 08, 2013 at 08:22:29PM -0400, Mark Anderson wrote:
> I think that's what we're getting at. I may have been imprecise in how
> I described it. I think we should have sone method to download and
> build some of the tools we need and set them aside.
I've given that a try and while it
stalled Tcl 8.6
> port into a new directory (e.g. /opt/local/lib/macports/Tcl)? Which
> variants of the tcl port that we currently have will work for this? What
> happens if a user installs a different variant? How do we solve the
> bootstrapping problem for users who want to build from
locate an installed Tcl 8.6
port into a new directory (e.g. /opt/local/lib/macports/Tcl)? Which
variants of the tcl port that we currently have will work for this? What
happens if a user installs a different variant? How do we solve the
bootstrapping problem for users who want to build from source? Should
Yeah, I've actually currently built against the MacPorts Tcl. I don't
recommend it, but it was the easiest way to rebuild between developer
seeds. I kind of like the idea Ryan was talking about where we build using
a portfile or something, and then squirrel the files away someplace awa
gt; MacPorts wouldn't be able to use cURL anymore. But as I said it's possibly
> worth looking into ways of solving it.
indeed, back a /long/ time ago I had built MacPorts against MacPorts provided
tcl and then forgotten and uninstalled MacPorts tcl (it was an interesting
situation to rec
On Jul 7, 2013, at 13:51, Mark Anderson wrote:
> Yeah. That was why I sort of just floated it as an idea. Mainly because of my
> troubles with a certain OSX that is not to be named or the fiery NDA demons
> will smite me.
>
> And now that you mentioned curl and subversion it's making more sens
Yeah. That was why I sort of just floated it as an idea. Mainly because of
my troubles with a certain OSX that is not to be named or the fiery NDA
demons will smite me.
And now that you mentioned curl and subversion it's making more sense to
me, since Macports likes to rely our own stuff to maximi
On Jul 6, 2013, at 17:50, Mark Anderson wrote:
> I'm starting to wonder if we should include a bootstrapping version of Tcl
> with Macports, in case some future version of OSX ships with a broken
> version. Any thoughts?
Yes, that topic recently came up. Someone pointed out that Tcl 8.6 offers
I'm starting to wonder if we should include a bootstrapping version of Tcl
with Macports, in case some future version of OSX ships with a broken
version. Any thoughts?
—Mark
___
Mark E. Anderson
___
macports-dev mailing list
macport
32 matches
Mail list logo
