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 platform.machin
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 ag
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
> 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 mail
> -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
>>> 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 w
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 k
>> 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 k
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
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
> 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
> -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
>
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 buil
>> 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
> From: Jamie Kirkpatrick [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 23 May 2007 5:16 AM
> 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 w
> 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
> -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; distutils-sig@python.org; python-
> [EMAIL PROTECTED]
> Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8
> -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
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python
> 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
> 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
> 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
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 and
> 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
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
> 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
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
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
> -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
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
55 matches
Mail list logo
