compromise proposal I
> outlined?
>
> Thanks,
>
> Mark
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Mark Hammond
> > Sent: Tuesday, 22 January 2008 9:06 PM
> > To: '"Martin v. Löw
; Cc: [EMAIL PROTECTED]; python-dev@python.org
> Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
>
> 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
> > hesita
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
> 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, install
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
> -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
>
> -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 around
> this mind-boggling stupidity, but life is
> 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 tha
> 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 th
>> 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 chan
]; python-
>> [EMAIL PROTECTED]
>> Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
>>
>> On 5/23/07, Kristján Valur Jónsson <[EMAIL PROTECTED]> wrote:
>> > > > Install in the ProgramFiles folder.
>> > > Only over my dead body.
> -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 engineeri
> -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 wit
> -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 bei
> -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 Py
> 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
> 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 th
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
--
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 kno
> - 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 doe
> 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
http://mail.python.org/m
> 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 wi
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 sinc
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
[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 th
> -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 a
> 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 s
> 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
> 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
>
> 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
bu
> 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
> -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 ha
> -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 si
> -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
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_
> 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
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
> 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
> 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 al
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 PROTECTE
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
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
>> 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
> 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'
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 separ
> -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
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
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 don't find the need to have separ
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 w
> * 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 wro
Hi all,
I hope the cross-post is appropriate.
I've started playing with getting the pywin32 extensions building under
the AMD64 architecture. I started building with Visual Studio 8 (it was
what I had handy) and I struck a few issues relating to the compiler version
that I thought worth shari
51 matches
Mail list logo
