I'm following up on this thread without checking if there were other
following negating a need to respond... If so, ignore as needed.
+1 from me. Always build on windows into an architecture specific
PCBuild/XXX directory. A bonus if the directory name matches the return
value of
Hi Martin,
Way back on Monday, 21 May 2007, you wrote:
This is an issue to be discussed for Python 2.6. I'm personally
hesitant to have the official build infrastructure deviate
from the layout that has been in-use for so many years, as a lot
of things depend on it.
I don't find the
-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED]
Just imagine the a school teacher who in good faith wants to
introduce
his pupils to the wonderful programming language of Python, but
when he installs it, all kinds of scary looking warnings drive him
off.
At 1:14 PM + 5/29/07, Kristján Valur Jónsson wrote:
-Original Message-
Microsoft's command line cannot cope with two pathnames that must be
quoted, so if the command path itself must be quoted, then no argument
to
the command can be quoted. There are tricky hacks that can work
One feature that is easily addable and will certainly make installing
python on vista nicer, is to add authenticode signing to the install.
This I question very much. I experimented with authenticode before 2.4,
and found it an unacceptable experience. When the MSI file starts
running,
It doesn't need to, and reluctance is not wrt. to the proposed new
layout, but wrt. changing the current one. Tons of infrastructure
depends on the files having exactly the names that they have now,
and being located in exactly the locations where they are currently
located. Any change to
Development tools used on windows already have to cope with this.
Spaces are not going away, so why not bite the bullet and deal
with them? Moving forward sometimes means crossing rivers.
But in a safe path, step by step. People continue to report problems
with spaces in file names, even
Supporting both kinds (country and western) on the same machine might be
helpful
to people for this very reason. A lot of legacy modules are only avaible
in 32 bit mode. But people may want to do contemporary development using the
new 64 bit mode.
Of course, people who really want that
-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED]
It doesn't need to, and reluctance is not wrt. to the proposed new
layout, but wrt. changing the current one. Tons of infrastructure
depends on the files having exactly the names that they have now,
and being
-Original Message-
From: Alexey Borzenkov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2007 20:36
To: Kristján Valur Jónsson
Cc: Martin v. Löwis; Mark Hammond; [EMAIL PROTECTED]; python-
[EMAIL PROTECTED]
Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
-Original Message-
I personally think that if hostile users can replace DLLs on your
system, you have bigger problems than SxS installation of
pythhonxy.dll,
but perhaps that's just me.
An end user application on an end-user's machine is always voulnerable
to reverse engineering.
At 12:20 PM + 5/26/07, Kristján Valur Jónsson wrote:
-Original Message-
From: Alexey Borzenkov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2007 20:36
To: Kristján Valur Jónsson
Cc: Martin v. Löwis; Mark Hammond; [EMAIL PROTECTED]; python-
[EMAIL PROTECTED]
Subject: Re:
-Original Message-
though, not cygwin (a la bsmedberg's new MozillaBuild stuff). I just
wish there were an autoconf alternative that wasn't as painful as
autoconf. I have a few attempts for my purposes that are written in
Python (an obvious bootstrapping problem for building Python
-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED]
That couldn't work for me. I try avoid building on a network drive, and
with local drives, I just can't have a Windows build and a Linux build
on the same checkout - they live on separate file systems, after all
[MarkH]
I'm guessing vsextcomp doesn't use the Visual
Studio 'ReleaseAMD64' configuration - would it be OK for me to check in
changes to the PCBuild projects for this configuration?
[Martin v. Löwis]
Please don't. It exclusively relies on vsextcomp, and is only useful
if you have that
It seems the
best thing might be to modify the PCBuild8 build process so the output
binaries are in the ../PCBuild' directory - this way distutils and others
continue to work fine. Does that sound reasonable?
I think Kristjan will have to say a word here: I think he just likes
it the way it is
On 5/23/07, Kristján Valur Jónsson [EMAIL PROTECTED] wrote:
Install in the ProgramFiles folder.
Only over my dead body. *This* is silly.
Bill doesn't think so. And he gets to decide. I mean we do want
to play nice, don't we? Nothing installs itself in the root anymore,
not since windows
Very well, leaving linux aside, I don't see why this:
/win32mount/trunk/PCbuild/
/x64mount/trunk/PCbuild/
Is any different from
/winmount/trunk/PCBuild/win32
/winmount/trunk/PCBuild/x64
I don't understand this extraordinary reluctance to add a single extra
directory.
The windows
I use this patch in ActivePython to get distutils to find the correct
PCbuild dir (see attached).
Would you like to commit this to 2.6? (or perhaps 2.5 even?)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
- Run the appropriate environment setup for the correct compiler. E.g.,
for the Platform SDK AMD64 compiler and with the current Platform SDK
this is:
C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd /X64 /RETAIL
- Run the solution file with devenv.com (IIRC, devenv.exe doesn't
Very well, leaving linux aside, I don't see why this:
/win32mount/trunk/PCbuild/
/x64mount/trunk/PCbuild/
Is any different from
/winmount/trunk/PCBuild/win32
/winmount/trunk/PCBuild/x64
In the former case, assuming python is running from the 'trunk' directory,
all architectures know how
Martin v. Löwis wrote:
I use this patch in ActivePython to get distutils to find the correct
PCbuild dir (see attached).
Would you like to commit this to 2.6? (or perhaps 2.5 even?)
Sure, if others think it is a good thing. Will do tomorrow unless I hear
a -1 before then.
Trent
--
Trent
Martin v. Löwis wrote:
I use this patch in ActivePython to get distutils to find
the correct
PCbuild dir (see attached).
Would you like to commit this to 2.6? (or perhaps 2.5 even?)
Sure, if others think it is a good thing. Will do tomorrow
unless I hear
a -1 before then.
I'm not
I'm not quite a '-1', but am a little confused about where this would leave
us. To some extent, this would formalize PCBuild8 and VC6 directories.
External tools would then slowly start growing support for these additional
directories and the previous benefits of PCBuild is the canonical
However, I think people ask much too often for a debugging build;
in many cases, they could work happily with a release build that
supports debugging. Depending on the problem you try to solve, you
may or may not need debug information for pythonxy.dll as well,
or just for your extension
Hi Mark,
+1 from me.
I think this is simply a bug introduced with the UCS4 patches in
Python 2.2.
unicodeobject.h already has this code:
#ifndef PY_UNICODE_TYPE
/* Windows has a usable wchar_t type (unless we're using UCS-4) */
# if defined(MS_WIN32) Py_UNICODE_SIZE == 2
# define
-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 22, 2007 05:33
To: Steve Holden
Cc: Kristján Valur Jónsson; Mark Hammond; [EMAIL PROTECTED];
python-dev@python.org
Subject: Re: Adventures with x64, VS7 and VS8 on Windows
Addressing only the
-Original Message-
Nobody proposed to ditch cross-compilation. I very much like
cross-compilation, I do all Itanium and AMD64 in cross-compilation.
I just want the *file structure* of the output to be the very same
for all architectures, meaning that they can't coexist in a single
-Original Message-
It seems the
best thing might be to modify the PCBuild8 build process so the
output
binaries are in the ../PCBuild' directory - this way distutils and
others
continue to work fine. Does that sound reasonable?
I think Kristjan will have to say a word
Someone mentioned the idea to have a bat file do it. I like
that idea. There is already a build.bat file which will
build whatever configuration you choose (platform and
configuration). Extending it to subsequently copy the
resulting binaries up one level is easy. Perhaps this is an
I'd be happy to install Windows and the latest VisualStudio on a 64-bit
VMware image. I just can't be responsible for day-to-day administration
of the buildslave; Windows requires too much attention for me to do
that.
Thanks for the offer. Perhaps Kristjan is interested in setting up a
While that is true in theory, I often find it is not the case in practice,
generally due to the optimizer. Depending on what magic the compiler has
done, it can be very difficult to set breakpoints (conditional or
otherwise), inspect variable values, etc. It is useful in some cases, but
Surely there are differences between architectures? PC uses MSI after all.
Why can't linux be under trunk/linux and pc 86 under trunk/pcbuild8/win32PGO
and 64 under trunk/pcbuild8/x64pgo?
That couldn't work for me. I try avoid building on a network drive, and
with local drives, I just can't
If there are no technical and corporate difficulties, such as
firewalls and security, I am sure that CCP can provide a
VisualStudio2005 buildbot for our needs. Wasn't there some issue that
each buildbot can only provide a single build?
Yes, but you can have multiple buildbot slaves on a
Hi Martin,
You are likely doing something wrong:
a) I assume it's VS 7.1 (i.e. VS.NET 2003); VS 2002 is not supported
at all
b) you probably didn't install vsextcomp, but you should.
In fact, you don't need all of it, but you do need the cl.exe and
link.exe wrappers it comes with -
On 2007-05-21 12:30, Kristján Valur Jónsson wrote:
[Py_UNICODE being #defined as unsigned short on Windows]
I'd rather make it a platform-specific definition (for platform=Windows
API). Correct me if I'm wrong, but isn't wchar_t also available in VS
2003 (and even in VC6?). And doesn't it
-Original Message-
This was in C++, but the problem was really WCHAR, as used by much of
the
win32 API.
I'd rather make it a platform-specific definition (for
platform=Windows
API). Correct me if I'm wrong, but isn't wchar_t also available in VS
2003 (and even in VC6?). And
Hi Kristján,
First of all, I have put some work into pcbuild8 recently and it works
well.
It does! There are a few issues though, notably with distutils (and as
mentioned before, any other tools what may assume PCBuild - see below)
You quoting Martin:
I don't find the need to have separate
I'm using the full-blown VS.NET 2003, as given to a number of python-dev
people by Microsoft a number of years ago. This appears to come with the
SDK and a 64bit compiler.
Not sure what it makes it appear to you that way - it doesn't. VS.NET
2003 is x86 only
I'm guessing vsextcomp doesn't
I don't find the need to have separate object directories convincing:
For building the Win32/Win64 binaries, I have separate checkouts
*anyway*, since all the add-on libraries would have to support
multi-arch builds, but I think they don't.
No they don't, but that doesn't mean that you need
Hi Marc-Andre,
+1 from me.
If think this is simply a bug introduced with the UCS4 patches in
Python 2.2.
unicodeobject.h already has this code:
#ifndef PY_UNICODE_TYPE
/* Windows has a usable wchar_t type (unless we're using UCS-4) */
# if defined(MS_WIN32) Py_UNICODE_SIZE == 2
#
Hi Martin,
I'm using the full-blown VS.NET 2003, as given to a number
of python-dev
people by Microsoft a number of years ago. This appears to
come with the
SDK and a 64bit compiler.
Not sure what it makes it appear to you that way - it doesn't. VS.NET
2003 is x86 only
Yes - I was
Kristján Valur Jónsson wrote:
First of all, I have put some work into pcbuild8 recently and it works
well. I am trying to drum up momentum for work on PCBuild8
next europython. See http://wiki.python.org/moin/EuroPython2007Sprints
-Original Message-
From: [EMAIL PROTECTED]
I
Yes, that is correct. I agree it will be rarely used by Python user's, but
believe it is a common scenario for people who maintain extensions or
libraries, particularly those who want debugging builds.
Ah, debugging builds. It's true that PCbuild does not support them for
AMD64, and it's also
Addressing only the issues of PCBuild8 and 64-bit architectures, I
have tried to establish free buildbot support for the 64-bit
architectures without any real success.
Should the PSF be considering paying for infrastructure that will
support 64-bit build reporting?
You can bring it up to
On Tue, May 22, 2007 at 07:32:42AM +0200, Martin v. L?wis wrote:
- Addressing only the issues of PCBuild8 and 64-bit architectures, I
- have tried to establish free buildbot support for the 64-bit
- architectures without any real success.
-
- Should the PSF be considering paying for
* In trying to build x64 from a 32bit VS7 (ie, cross-compiling via the
PCBuild directory), the python.exe project fails with:
pythoncore fatal error LNK1112: module machine type 'X86' conflicts with
target machine type 'AMD64'
is this a known issue, or am I doing something wrong?
47 matches
Mail list logo
