On Saturday 08 January 2005 00:05, Jack Jansen wrote:
> > This patch implements the proposed direct framework linking:
> > http://python.org/sf/1097739
>
> Looks good, I'll incorporate it. And as I haven't heard of any
> showstoppers for the -undefined dynamic_lookup (and Anthony seems to be
> offl
On 7 Jan 2005, at 11:08, Bob Ippolito wrote:
10.3 or later. For older OSX releases (either because you build
Python on 10.2 or earlier, or because you've set
MACOSX_DEPLOYMENT_TARGET to a value of 10.2 or less) we use the old
behaviour of linking with "-framework Python".
Wouldn't it be better t
On Jan 6, 2005, at 15:03, Bob Ippolito wrote:
On Jan 6, 2005, at 14:59, Ronald Oussoren wrote:
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and
On Jan 6, 2005, at 14:59, Ronald Oussoren wrote:
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal
Ronald Oussoren wrote:
Wouldn't it be better to link with the actual dylib inside the framework
on 10.2? Otherwise you can no longer build 2.3 extensions after you've
installed 2.4.
That's what I thought, too.
Regards,
Martin
___
Python-Dev mailing list
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal preference, but at least we know that
loading a
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal preference, but at least we know that
loading an extension into one Python won't bring i
On Jan 5, 2005, at 18:49, Martin v. Löwis wrote:
Jack Jansen wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal preference, but at least we know that
loading an extension into one
On Jan 5, 2005, at 18:46, Martin v. Löwis wrote:
Bob Ippolito wrote:
I just dug up some information I had written on this particular topic
but never published, if you're interested:
http://bob.pythonmac.org/archives/2005/01/05/versioned-frameworks-
considered-harmful/
Interesting. I don't get
Jack Jansen wrote:
But I do care:-) Specifically because I trust the crowd here to come up
with good ideas (even if they're not Mac users:-).
Thanks a lot.
The "new" solution is basically to go back to the Unix way of building
an extension: link it against nothing and sort things out at runtime
Bob Ippolito wrote:
I just dug up some information I had written on this particular topic
but never published, if you're interested:
http://bob.pythonmac.org/archives/2005/01/05/versioned-frameworks-
considered-harmful/
Interesting. I don't get the part why "-undefined dynamic_lookup"
is a good
[Grmpf. I should check which account I use before pressing send. Here
goes again]
On 5-jan-05, at 1:08, Bob Ippolito wrote:
The problem we're trying to solve is that due to the way Apple's
framework architecture works newer versions of frameworks are
preferred (at link time, and sometimes ev
On Jan 5, 2005, at 17:38, Martin v. Löwis wrote:
Bob Ippolito wrote:
Nope. The only way to link to a non-current framework version is to
forego any linker searching and specify the dyld file directly, i.e.
/Library/Frameworks/Python.framework/Versions/2.3/Python. The gcc
toolchain does not
Bob Ippolito wrote:
Nope. The only way to link to a non-current framework version is to
forego any linker searching and specify the dyld file directly, i.e.
/Library/Frameworks/Python.framework/Versions/2.3/Python. The gcc
toolchain does not in any way whatsoever understand versioned
framewor
Michael Hudson wrote:
Martin, can you please believe that Jack, Bob, Ronald et al know what
they are talking about here?
I find that really hard to believe, because it contradicts to what I
think Apple wants me to believe. I'm willing to follow a series of
statements that I can confirm to be facts
On Jan 5, 2005, at 16:58, Martin v. Löwis wrote:
Ronald Oussoren wrote:
It gets worse when you have a user-installed python 2.3 and a
user-installed python 2.4. Those will be both be installed as
/Library/Frameworks/Python.framework.
Yes, but one is installed in Versions/2.3, and the other in
Ver
Ronald Oussoren wrote:
It gets worse when you have a user-installed python 2.3 and a
user-installed python 2.4. Those will be both be installed as
/Library/Frameworks/Python.framework.
Yes, but one is installed in Versions/2.3, and the other in
Versions/2.4.
This means that you cannot use the
-
On Jan 5, 2005, at 16:15, Martin v. Löwis wrote:
Bob Ippolito wrote:
Then you haven't done the appropriate research by searching
pythonmac-sig.
Hmm.
> Do you even own a Mac?
Do I have to, in order to understand the issues?
But to answer your question: yes, I do.
Well, this issue has been discussed
Bob Ippolito wrote:
Then you haven't done the appropriate research by searching
pythonmac-sig.
Hmm.
> Do you even own a Mac?
Do I have to, in order to understand the issues?
But to answer your question: yes, I do.
Regards,
Martin
___
Python-Dev mailing
On Jan 5, 2005, at 3:33 AM, Martin v. Löwis wrote:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is
that you specifically do not want to link directly to the framework
at all when buildin
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Bob Ippolito wrote:
>> It doesn't for reasons I care not to explain in depth, again.
>> Search the pythonmac-sig archives for longer explanations. The
>> gist is that you specifically do not want to link directly to the
>> framework at all when b
On 2005 Jan 05, at 12:40, Ronald Oussoren wrote:
...
The Tiger that was released at WWDC included a patched version of
Python 2.3.3. See:
http://www.opensource.apple.com/darwinsource/WWDC2004/.
Thanks! So, since WWDC was on June 28 and 2.3.4 had been released on
May 27, we get some first sen
On 5-jan-05, at 12:28, Alex Martelli wrote:
On 2005 Jan 05, at 00:06, Jack Jansen wrote:
...
We've solved this issue for the trunk and we can solve it for 2.4.1:
if MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it
to 10.3. Moreover, when it is 10.3 or higher (possibly after bei
On 2005 Jan 05, at 00:06, Jack Jansen wrote:
...
We've solved this issue for the trunk and we can solve it for 2.4.1:
if MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it to
10.3. Moreover, when it is 10.3 or higher (possibly after being
forced) we use the dynamic_lookup way of
On 5-jan-05, at 9:33, Martin v. Löwis wrote:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is
that you specifically do not want to link directly to the framework
at all when building exte
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is that
you specifically do not want to link directly to the framework at all
when building extensions.
Because an Apple-built extension then
On Jan 4, 2005, at 6:54 PM, Martin v. Löwis wrote:
Jack Jansen wrote:
First question: what is the Python 2.3.5 release schedule and who is
responsible?
Last I heard it is going to be released "in January", and Anthony
Baxter
is the release manager.
Second question: I thought this info was in a
Jack Jansen wrote:
First question: what is the Python 2.3.5 release schedule and who is
responsible?
Last I heard it is going to be released "in January", and Anthony Baxter
is the release manager.
Second question: I thought this info was in a PEP somewhere, but I could
only find PEPs on major re
First question: what is the Python 2.3.5 release schedule and who is
responsible?
Second question: I thought this info was in a PEP somewhere, but I
could only find PEPs on major releases, should I have found this info
somewhere?
And now the question that matters: there's some stuff I'd really
First question: what is the Python 2.3.5 release schedule and who is
responsible?
Second question: I thought this info was in a PEP somewhere, but I
could only find PEPs on major releases, should I have found this info
somewhere?
And now the question that matters: there's some stuff I'd really
30 matches
Mail list logo
