> -----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 > (Linux on ext3, Windows on NTFS, with multi-boot switching between > them). 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 build process is different from any other build process, so even If all the other platforms live one directory higher, why must windows? > I don't *use* them simultaneously, of course - I cannot work > on two architectures simultaneously, anyway. I do so on a daily basis. I designed PCBuild8 to be easy for interactive work using VisualStudio, using property sheets and such to group common settings for easy editing. During the course of my work, I will edit a file (which is checked out from Perforce), compile debug for two platforms, test, and repeat. > > > I say let's just admit that tools can compile for > > more than one target. Let's adapt to it and we will all be happier. > > You might be; I will be sad. It comes for a price, I well understand the benefits, I use it all the time, but the price still eludes me. how can a different name for the output folder for a different platform be such a big problem? > > And btw, there is no need to install the msvcr8.dll. We can > distribute > > them as a private assembly. then they (and the manifest) exist in > the same > > directory as python2x.dll. > > Yes, but then python2x.dll goes into system32, and so will msvcr8.dll, > no? Yes, that is correct. Well, there is a CRT .exe redist if you want to deploy this into the SxS cache, it just has to be run as part of the install process. But that may or may not be problematic, I don't know. > > >> Not sure whether anything really is needed. Python works fine on > Vista. > > If you are an administrator. A limited user will have problems > installing > > it and then running it. > > Is there a bug report for that? I don't know. At any rate, I think any vista issues is a completely separate thing, something that needs to be handled as a whole, rather than responding to a particular problem reported in a bug report. > > >>> 1) supplying python.dll as a Side By Side assembly > >> What would that improve? > > Well, it should reduce dll-hell problems of applications that ship > with > > python2x.dll. You ship with and link to your own and tested dll. We > > have some concerns here, for example, now that we are moving away > from > > embedding python in our blue.dll and using python25.dll directly, > that > > this exposes a vulnerability to the integrity of the software. > > Why should there be versioning problems with python25.dll? Are there > any past issues with incompatibilities with any python2x.dll release? Someone could replace the python25.dll that we ship with their own patched version, thereby gaining backdoor access to the software. The way windows searches for old style dlls makes this easy. Using the SxS signed loading scheme, you can protect yourself up to a point from such attacks. Of course, this doesn't have to be a problem for vanilla python, we can do this on our own for the patched python25 that we employ, but it still might be something others could find useful. > > 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 3.1 > > > Just as C does. Ah, and > > this also means that we could install both 32 bit and 64 bit > > versions, another plus. > > What about the registry? I don't know about the registry, what is it used for? 64 bit windows already ships with dual versions of some apps, notably explorer.exe so that shouldn't be a big problem. > > > Interesting. We are definitely interested in that. You see, Someone > > installs a game or accounting software using vista. He then runs as > a > > limited user. Python insists on saving its .pyc files in the > installation > > folder, but this is not something that is permitted on Vista. > > But that's not a problem, is it? Writing silently "fails", i.e. it just > won't save the pyc files. Happens all the time on Unix. It may not silently fail, depending on your user status. An admin might get a confirmation window, for example. > > >> Sure, and have they reported problems with Python on Vista (problems > >> specific to Vista?) > > Certainly. We are working on them, of course. > > But, of course, they have not been reported. These are not python errors as such, but rather EVE errors. We ship the .py files precompiled and therefore avoid the aforementioned problems. But we have had to move all sorts of temporary files out of "program files" and into "documents and settings/user/local settings/Application Data/CCP/Eve Kristjan _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
