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
I'm wondering if anyone has any comment on this issue? Its currently
impossible to use distutils as documented to build x64 extensions, either
natively or cross-compiled using the trunk and while I'm keen to help fix
this, I'd like agreement on the direction.
Can I assume silence means general
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
Dear Martin,
Educated, adult developers with good internet connections may know that,
but all users? What about software on a CD or a memory stick?
Also, I believe users *still* get a confirmation window, just the
message changes from we don't know who wrote this software to
we know PSF
Educated, adult developers with good internet connections may know that,
but all users? What about software on a CD or a memory stick?
Also, I believe users *still* get a confirmation window, just the
message changes from we don't know who wrote this software to
we know PSF wrote it - do you
-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED]
Yes, I am aware of that. But the signature makes a man-in-the-middle
attack harder.
Sure. However, I think that this protection against an unlikely
scenario
cannot outweigh the main problem of code signing:
Us trying to lecture MS on software security is pointless.
I didn't try to lecture MS. I explained that to Lars Immisch,
who essentially said that authenticode is a good thing because
it is based on certificates.
Regards,
Martin
___
Distutils-SIG
Martin v. Löwis wrote:
I have a set of extensions that use SWIG to wrap my own C++ library.
This library, on a day-to-day basis is built against VS8 since the rest
of our product suite is. Right now I have no way to work with this code
using VS8 since the standard distribution is built
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,
Hi,
One feature that is easily addable and will certainly make installing
python on vista nicer, is to add authenticode signing to the install.
I'm +1 on authenticode.
This I question very much. I experimented with authenticode before 2.4,
and found it an unacceptable experience. When the
Certainly. However, telling them that they have to wait just so that
Windows finds out what they know already (that this is the MSI file
from the Python Software Foundation, or from Martin v. Löwis) is
even more nasty.
Educated, adult developers with good internet connections may know that,
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
Is there a shell script to build a final distribution tree? If
not, is there a simple way to build an MSI similar to the one found
on the Python.org site for the official releases but using the
PCBuild8 stuff?
I believe not.
It's actually not that difficult. You just have to run
-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; distutils-sig@python.org; python-
[EMAIL PROTECTED]
Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on
-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.
-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
___
Distutils-SIG maillist - Distutils-SIG@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
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
-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
I recommend that those people install the official binaries. Why do
you
need to build the binaries from source, if all you want is to build
extensions?
I've been following this discussion and it seems like an appropriate
place to mention such a scenario which I have encountered myself
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
I have a set of extensions that use SWIG to wrap my own C++ library.
This library, on a day-to-day basis is built against VS8 since the rest
of our product suite is. Right now I have no way to work with this code
using VS8 since the standard distribution is built against VS7 which
uses 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
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
#
40 matches
Mail list logo
