[Python-Dev] Testing 3.3 framework builds on OS X
Anyone know how to build and run tests on an OS X build with —enable-framework, without installing the framework? I want to test that something works in my tree without polluting /Library/Frameworks with stuff that could mess up future tests. I've been mucking around with DYLD_FRAMEWORK_PATH but not having much luck. If I build with ./configure --enable-framework --with-dtrace && make and use DYLD_FRAMEWORK_PATH=. then I suspect it's still loading from /Library/Frameworks, because my tests fail in a way that suggests it's not finding the new bits in my working directory. If I build with ./configure --enable-framework=. --with-dtrace && make and use DYLD_FRAMEWORK_PATH=., then it fails with: dyld: Library not loaded: ./Python.framework/Versions/3.3/Python presumably because ./Python.framework doesn't have any .dylib's or .so's. Thanks, Marc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing 3.3 framework builds on OS X
In article
,
Marc Abramowitz wrote:
> Anyone know how to build and run tests on an OS X build with
> enable-framework, without installing the framework? I want to test
> that something works in my tree without polluting /Library/Frameworks
> with stuff that could mess up future tests.
>
> I've been mucking around with DYLD_FRAMEWORK_PATH but not having much luck.
>
> If I build with ./configure --enable-framework --with-dtrace && make
> and use DYLD_FRAMEWORK_PATH=. then I suspect it's still loading from
> /Library/Frameworks, because my tests fail in a way that suggests it's
> not finding the new bits in my working directory.
>
> If I build with ./configure --enable-framework=. --with-dtrace && make
> and use DYLD_FRAMEWORK_PATH=., then it fails with:
>
> dyld: Library not loaded: ./Python.framework/Versions/3.3/Python
>
> presumably because ./Python.framework doesn't have any .dylib's or .so's.
Read the updated Mac/README for more information about framework builds.
Here's a sample configure I use to minimize the chances of pollution
from other installed Pythons:
BASEDIR="$(dirname $(pwd -P))"
[ -n "${BASEDIR}" ] && ./configure --enable-universalsdk
--with-universal-archs=intel
--enable-framework="${BASEDIR}"/root/Library/Frameworks
--with-framework-name=pytest_10_7 --with-pydebug && rm -rf
"${BASEDIR}"/root/* || echo "ERROR: configure failed"
This is for 3.3 on 10.7. For 3.2 and 2.7 at the moment you also need to
explicitly set MACOSX_DEPLOYMENT_TARGET=10.7 and CC=clang.
The framework path probably needs to be an absolute path, BTW.
--
Ned Deily,
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing 3.3 framework builds on OS X
In article ,
Ned Deily wrote:
> Read the updated Mac/README for more information about framework builds.
> Here's a sample configure I use to minimize the chances of pollution
> from other installed Pythons:
>
> BASEDIR="$(dirname $(pwd -P))"
> [ -n "${BASEDIR}" ] && ./configure --enable-universalsdk
> --with-universal-archs=intel
> --enable-framework="${BASEDIR}"/root/Library/Frameworks
> --with-framework-name=pytest_10_7 --with-pydebug && rm -rf
> "${BASEDIR}"/root/* || echo "ERROR: configure failed"
This does require that you run "make install" but everything is safely
installed at ../root, including Library/Frameworks, usr/bin, and
Applications directories.
--
Ned Deily,
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 108, Issue 7
thanks for the reply hastings ive been working on a loopback interface its done On Fri, Jul 6, 2012 at 3:00 AM, wrote: > Send Python-Dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-Dev digest..." > > > Today's Topics: > >1. Re: GitHub mirror (Was: Bitbucket mirror?) ([email protected]) >2. Bloody FAQ (Was: [Python-ideas] itertools.chunks(iterable, > size, fill=None)) (anatoly techtonik) >3. Re: Bloody FAQ (Was: [Python-ideas] > itertools.chunks(iterable, size, fill=None)) (Mark Lawrence) >4. Re: Bloody FAQ (Was: [Python-ideas] > itertools.chunks(iterable, size, fill=None)) (Stefan Behnel) >5. Re: Bloody FAQ (Was: [Python-ideas] > itertools.chunks(iterable, size, fill=None)) (Paul Boddie) >6. EuroPython 2012 Language Summit is Canceled. (Larry Hastings) > > > -- > > Message: 1 > Date: Thu, 05 Jul 2012 20:27:02 +0200 > From: [email protected] > To: [email protected] > Subject: Re: [Python-Dev] GitHub mirror (Was: Bitbucket mirror?) > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes > > >> You won't get any changes in to CPython by creating pull requests. We > >> use http://bugs.python.org/ for that, sorry. > > > > Question -- is there a reason to abide by this rule for docs? That is, > if we > > could get a sympathetic core dev to look at pull requests for docs as > part of > > a streamlined process, would it cause problems? > > How do you communicate a "pull request"? On bitbucket, there is a > "pull request" > UI resulting in a tracker item being generated (and an email being sent), > but > hg.python.org doesn't have a notion of pull requests. Of course, you could > use any communication means (email, telephone call, carrier pigeon) to > request > a pull from a "sympathetic core dev". > > > (What I'm really asking is whether or the bugs.python.org process is > > considered critical for potentially minor doc changes and additions.) > > The sympathetic core dev is mostly free to bypass any submission process > initially; commits that bypass established procedures will likely be > questioned > only after the fact. > > In the specific case, I'd be worried to verify that the submitter has > provided > a contributor form. That's easy to do in the bug tracker, but difficult to > do > in an offline pull request. Of course, for a really minor doc change > (e.g. typo > fixes), no contrib form is necessary. > > Regards, > Martin > > > > > -- > > Message: 2 > Date: Thu, 5 Jul 2012 22:41:29 +0300 > From: anatoly techtonik > To: Stefan Behnel > Cc: [email protected], [email protected] > Subject: [Python-Dev] Bloody FAQ (Was: [Python-ideas] > itertools.chunks(iterable, size, fill=None)) > Message-ID: > [email protected]> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Jul 5, 2012 at 7:50 PM, Stefan Behnel wrote: > > anatoly techtonik, 05.07.2012 15:36: > >> On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: > >>> From Raymond's first message on http://bugs.python.org/issue6021 , add > >>> grouper: > >>> > >>> "This has been rejected before. > >> > >> I quite often see such arguments and I can't stand to repeat that > >> these are not arguments. It is good to know, but when people use that > >> as a reason to close tickets - that's just disgusting. > > > > The *real* problem is that people keep bringing up topics (and even spell > > them out in the bug tracker) without searching for existing discussions > > and/or tickets first. That's why those who do such a search (or who know > > what they are talking about anyway) close these tickets with the remark > > "this has been rejected before", instead of repeating an entire heap of > > arguments all over again to feed a discussion that would only lead to the > > same result as it did before, often several times before. > > Make the bloody FAQ and summarize this stuff? Why waste each others > time? If people don't enjoy repeating themselves over and over - there > is a bloody wiki. What should happen to people to start extracting > gems of knowledge from piles of dusty sheets called list "archives" > for others to admire. > > No, it is easier to say "it was already discussed many times", "why > don't you Google yourself", "so far you're only complaining", etc. If > people can't find anything - why everybody thinks they are ignorant
Re: [Python-Dev] Python-Dev Digest, Vol 108, Issue 7
spoke too early on its done sorry On Tue, Jul 10, 2012 at 2:04 PM, Ryan Paullin wrote: > thanks for the reply hastings ive been working on a loopback interface its > done > > > On Fri, Jul 6, 2012 at 3:00 AM, wrote: > >> Send Python-Dev mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mail.python.org/mailman/listinfo/python-dev >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Python-Dev digest..." >> >> >> Today's Topics: >> >>1. Re: GitHub mirror (Was: Bitbucket mirror?) ([email protected]) >>2. Bloody FAQ (Was: [Python-ideas] itertools.chunks(iterable, >> size, fill=None)) (anatoly techtonik) >>3. Re: Bloody FAQ (Was: [Python-ideas] >> itertools.chunks(iterable, size, fill=None)) (Mark Lawrence) >>4. Re: Bloody FAQ (Was: [Python-ideas] >> itertools.chunks(iterable, size, fill=None)) (Stefan Behnel) >>5. Re: Bloody FAQ (Was: [Python-ideas] >> itertools.chunks(iterable, size, fill=None)) (Paul Boddie) >>6. EuroPython 2012 Language Summit is Canceled. (Larry Hastings) >> >> >> -- >> >> Message: 1 >> Date: Thu, 05 Jul 2012 20:27:02 +0200 >> From: [email protected] >> To: [email protected] >> Subject: Re: [Python-Dev] GitHub mirror (Was: Bitbucket mirror?) >> Message-ID: >> <[email protected]> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes >> >> >> You won't get any changes in to CPython by creating pull requests. We >> >> use http://bugs.python.org/ for that, sorry. >> > >> > Question -- is there a reason to abide by this rule for docs? That is, >> if we >> > could get a sympathetic core dev to look at pull requests for docs as >> part of >> > a streamlined process, would it cause problems? >> >> How do you communicate a "pull request"? On bitbucket, there is a >> "pull request" >> UI resulting in a tracker item being generated (and an email being sent), >> but >> hg.python.org doesn't have a notion of pull requests. Of course, you >> could >> use any communication means (email, telephone call, carrier pigeon) to >> request >> a pull from a "sympathetic core dev". >> >> > (What I'm really asking is whether or the bugs.python.org process is >> > considered critical for potentially minor doc changes and additions.) >> >> The sympathetic core dev is mostly free to bypass any submission process >> initially; commits that bypass established procedures will likely be >> questioned >> only after the fact. >> >> In the specific case, I'd be worried to verify that the submitter has >> provided >> a contributor form. That's easy to do in the bug tracker, but difficult >> to do >> in an offline pull request. Of course, for a really minor doc change >> (e.g. typo >> fixes), no contrib form is necessary. >> >> Regards, >> Martin >> >> >> >> >> -- >> >> Message: 2 >> Date: Thu, 5 Jul 2012 22:41:29 +0300 >> From: anatoly techtonik >> To: Stefan Behnel >> Cc: [email protected], [email protected] >> Subject: [Python-Dev] Bloody FAQ (Was: [Python-ideas] >> itertools.chunks(iterable, size, fill=None)) >> Message-ID: >> > [email protected]> >> Content-Type: text/plain; charset=UTF-8 >> >> On Thu, Jul 5, 2012 at 7:50 PM, Stefan Behnel >> wrote: >> > anatoly techtonik, 05.07.2012 15:36: >> >> On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: >> >>> From Raymond's first message on http://bugs.python.org/issue6021 , >> add >> >>> grouper: >> >>> >> >>> "This has been rejected before. >> >> >> >> I quite often see such arguments and I can't stand to repeat that >> >> these are not arguments. It is good to know, but when people use that >> >> as a reason to close tickets - that's just disgusting. >> > >> > The *real* problem is that people keep bringing up topics (and even >> spell >> > them out in the bug tracker) without searching for existing discussions >> > and/or tickets first. That's why those who do such a search (or who know >> > what they are talking about anyway) close these tickets with the remark >> > "this has been rejected before", instead of repeating an entire heap of >> > arguments all over again to feed a discussion that would only lead to >> the >> > same result as it did before, often several times before. >> >> Make the bloody FAQ and summarize this stuff? Why waste each others >> time? If people don't enjoy repeating themselves over and over - there >> is a bloody wiki. What should happen to people to start extracting >> gems of knowledge from piles of dusty sheets called list "archives" >> f
Re: [Python-Dev] Testing 3.3 framework builds on OS X
On 10 Jul, 2012, at 18:41, Marc Abramowitz wrote: > Anyone know how to build and run tests on an OS X build with > —enable-framework, without installing the framework? I want to test > that something works in my tree without polluting /Library/Frameworks > with stuff that could mess up future tests. > > I've been mucking around with DYLD_FRAMEWORK_PATH but not having much luck. > Setting DYLD_FRAMEWORK_PATH should work and is whtat's used for RUNSHARED in the Makefile. I regularly build using 'configure --enable-framework' and then use 'make test' to test that build. This runs the python.exe in the build directory with DYLD_FRAMEWORK_PATH set to the build directory (as an absolute path). Ronald > > Thanks, > Marc > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
