On 15 March 2016 at 08:04, Nick Coghlan wrote:
> On 15 March 2016 at 15:15, Martin Panter wrote:
>> _freeze_importlib.o: _freeze_importlib.c Makefile
>>
>> _freeze_importlib: _freeze_importlib.o [. . .]
>> $(LINKCC) [. . .]
>>
>> importlib_external.h: _bootstrap_external.py _freeze_import
On 15 March 2016 at 15:15, Martin Panter wrote:
> The problem is not the reference to Makefile. The graminit files do
> not depend on Makefile. The bigger problem is that the checked-in
> files depend on compiled programs. This is a summary of the current
> rules for importlib:
>
> _freeze_importl
On 15 March 2016 at 04:32, Nick Coghlan wrote:
> On 15 March 2016 at 10:49, Martin Panter wrote:
>> One more idea I am considering is to decouple the makefile rules from
>> the main build. So to update the generated files you would have to run
>> a separate command like “make graminit” or “make f
On 15 March 2016 at 10:49, Martin Panter wrote:
> One more idea I am considering is to decouple the makefile rules from
> the main build. So to update the generated files you would have to run
> a separate command like “make graminit” or “make frozen”. The normal
> build would never regenerate the
On 14 March 2016 at 13:26, R. David Murray wrote:
> On Mon, 14 Mar 2016 03:04:08 -, "Gregory P. Smith"
> wrote:
>> On Sun, Mar 13, 2016 at 7:41 PM Martin Panter wrote:
>> > Include/graminit.h
>> > Python/graminit.c
>> > Python/importlib.h
>> > Python/importlib_external.h
>> >
>> > A questio
On 03/14/2016 05:34 PM, Xavier de Gaye wrote:
> Changeset c2a53aa27cad [1] was commited in issue 22359 [2] to remove incorrect
> uses of recursive make. The changeset added executable binaries as
> prerequisites to the existing rules (Python/importlib.h and $(GRAMMAR_H)).
> This broke cross-compi
On 03/14/2016 02:26 PM, R. David Murray wrote:
>
> The repo-timestamp problem is addressed by the 'make touch' target.
>
> And yes, checking in these platform-independent artifacts is very
> intentional: less to build, fewer external dependencies in the build
> process...you don't need to *have* p
On Mon, 14 Mar 2016 03:04:08 -, "Gregory P. Smith" wrote:
> On Sun, Mar 13, 2016 at 7:41 PM Martin Panter wrote:
>
> > On 13 March 2016 at 01:13, Russell Keith-Magee
> > wrote:
> > > The patches that I've uploaded to Issue23670 [1] show a full
> > cross-platform
> > > [1] http://bugs.python
On 14 March 2016 at 13:04, Gregory P. Smith wrote:
> They should not be regenerated every build, if they are, that seems like a
> bug in the makefile to me (or else the timestamp checks that make does vs
> how your code checkout happened). Having them checked in is convenient for
> cross builds a
cally they're fine and the
first build succeeds.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Martin Panter"
Sent: 3/13/2016 19:43
To: "Russell Keith-Magee" ; "python-dev"
Cc: "anto...@python.org"
Subje
On Sun, Mar 13, 2016 at 7:41 PM Martin Panter wrote:
> On 13 March 2016 at 01:13, Russell Keith-Magee
> wrote:
> > The patches that I've uploaded to Issue23670 [1] show a full
> cross-platform
> > [1] http://bugs.python.org/issue23670
> > build process. After you apply that patch, the iOS direct
On 13 March 2016 at 01:13, Russell Keith-Magee wrote:
> The patches that I've uploaded to Issue23670 [1] show a full cross-platform
> [1] http://bugs.python.org/issue23670
> build process. After you apply that patch, the iOS directory contains a
> meta-Makefile that manages the build process.
Tha
On 11 March 2016 at 23:16, Russell Keith-Magee wrote:
>
> On Sat, Mar 12, 2016 at 6:38 AM, Martin Panter wrote:
>> make clean # Work around confusion with existing in-source build
>> mkdir native
>> (cd native/ && ../configure)
>> make -C native/ Parser/pgen
>> mkdir mingw
>> (cd mingw/ && ../co
On Sat, Mar 12, 2016 at 6:38 AM, Martin Panter wrote:
> Hi Russell. Sorry for the minor ~1 month delay in replying :)
>
> I have been doing some experimenting to see what is involved in
> cross-compiling Python (Native host = Linux, target = Windows via
> mingw and some patches). So I have a slig
Hi Russell. Sorry for the minor ~1 month delay in replying :)
I have been doing some experimenting to see what is involved in
cross-compiling Python (Native host = Linux, target = Windows via
mingw and some patches). So I have a slightly better understanding of
the problem than before.
On 16 Febr
On Tue, Feb 16, 2016 at 5:22 AM, Martin Panter wrote:
> On 15 February 2016 at 08:24, Russell Keith-Magee
> wrote:
> > Hi all,
> >
> > I’ve been working on developing Python builds for mobile platforms, and
> I’m
> > looking for some help resolving a bug in Python’s build system.
> >
> > The pro
On 15 February 2016 at 08:24, Russell Keith-Magee
wrote:
> Hi all,
>
> I’ve been working on developing Python builds for mobile platforms, and I’m
> looking for some help resolving a bug in Python’s build system.
>
> The problem affects cross-platform builds - builds where you are compiling
> pyth
Hi all,
I’ve been working on developing Python builds for mobile platforms, and I’m
looking for some help resolving a bug in Python’s build system.
The problem affects cross-platform builds - builds where you are compiling
python for a CPU architecture other than the one on the machine that is
do
18 matches
Mail list logo
