From barry@zope.com Sat Jun 1 00:35:01 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri May 31 23:35:01 2002 Subject: [Distutils] Skipping compilation of some .py files on "install"? References: <15599.46868.995241.746225@anthem.wooz.org> <3CF1F35D.90101@lemburg.com> Message-ID: <15608.16553.814573.513885@anthem.wooz.org> >>>>> "MAL" == M writes: >> The email package has two files to help it maintain >> compatibility with Python 2.1 and Python 2.2+. There's a >> _compat21.py and a _compat22.py that contains tricky bits that >> are different between the two Python versions. >> [...] >> Naturally Python 2.1 won't be able to compile _compat22.py and >> indeed you get a SyntaxError. Is there a way >> -- in my setup.py -- that I can [...] skip byte >> compilation of _compat22.py when I find I'm using Python 2.1? MAL> Not builtin, but it should be easy to write your own subclass MAL> which implements this. And indeed it was! Thanks for the hint MAL. Below is what I came up with. -Barry -------------------- snip snip --------------------setup.py import sys from os.path import basename from distutils.core import setup from distutils.command.install_lib import install_lib class EmailInstall(install_lib): def byte_compile(self, files): # For Python 2.1.x do not byte compile the _compat22.py file since # that will most definitely fail. Any newer Python can compile # everything. major, minor = sys.version_info[0:2] if major == 2 and minor == 1: files = [f for f in files if basename(f) <> '_compat22.py'] return install_lib.byte_compile(self, files) setup(name='email', version='2.0.5', description='Next generation MIME library', author='Barry Warsaw', author_email='barry@zope.com', url='http://sf.net/projects/mimelib', packages=['email'], # Because we need to selectively byte-compile cmdclass={'install_lib': EmailInstall}, ) From jeremy@zope.com Tue Jun 4 15:28:01 2002 From: jeremy@zope.com (Jeremy Hylton) Date: Tue Jun 4 14:28:01 2002 Subject: [Distutils] updated SF patch In-Reply-To: <20020531185553.GD30128@ute.mems-exchange.org> References: <15607.45112.635217.260785@slothrop.zope.com> <3CF7B348.4010406@lemburg.com> <15607.46652.202327.728166@slothrop.zope.com> <20020531185553.GD30128@ute.mems-exchange.org> Message-ID: <15612.50124.189533.335448@slothrop.zope.com> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Fri, May 31, 2002 at 01:43:24PM -0400, Jeremy Hylton wrote: >> Good point. Is the core API documented anywhere? I can't tell >> what is intended to be part of the API and what is accidentally >> exposed by the implementation. AMK> No reference docs were ever written, AFAIK, so we'll just have AMK> to follow Python convention: methods prefixed with an AMK> underscore are private, otherwise public. I'm wondering more about the goal of preserving backwards compatibility of an undocumented interface for extension writers. How many extensions have been written? Do we have any idea how many people use this or would be affected? If it's just a handful of people, I wonder if it would be easier to trying to define a small API that they can rely on and give up on backwards compatibility. not-inteding-to-deliberately-incite-riot-ly y'rs, Jeremy From pearu@cens.ioc.ee Tue Jun 4 20:14:03 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Tue Jun 4 19:14:03 2002 Subject: [Distutils] updated SF patch In-Reply-To: <15612.50124.189533.335448@slothrop.zope.com> Message-ID: On Tue, 4 Jun 2002, Jeremy Hylton wrote: > >>>>> "AMK" == Andrew Kuchling writes: > > AMK> On Fri, May 31, 2002 at 01:43:24PM -0400, Jeremy Hylton wrote: > >> Good point. Is the core API documented anywhere? I can't tell > >> what is intended to be part of the API and what is accidentally > >> exposed by the implementation. > > AMK> No reference docs were ever written, AFAIK, so we'll just have > AMK> to follow Python convention: methods prefixed with an > AMK> underscore are private, otherwise public. > > I'm wondering more about the goal of preserving backwards > compatibility of an undocumented interface for extension writers. How > many extensions have been written? Do we have any idea how many > people use this or would be affected? > > If it's just a handful of people, I wonder if it would be easier to > trying to define a small API that they can rely on and give up on > backwards compatibility. For your information, the module scipy_distutils from the SciPy (www.scipy.org) package extends distutils quite a bit: it provides definitions for a dozen of Fortran 77/90/95 compilers from different vendors, it supports compilation of Fortran sources and building (automatically generated) extension modules to wrap Fortran and C libraries, etc. To achieve all that many hooks from the standard distutils needed to be extended and I cannot imagine if all that could have be done using just a "small" API (whatever that would be). However, I don't know what kind of changes are you planning and therefore I am not sure if they would have any impact to scipy_distutils. Hopefully it will be positive in the sense that it would work with Python versions starting from 2.1 and ending with the latest. So, some backwards compatibility is appreciated. What is the definition of handful people? Do you count extension developers or the users of these extensions? If the later, one would really need lots of hands when considering the current user base of SciPy alone (to give some idea, currently there are more than 100 subscribers to the scipy users mailing list formed in less than one year). Regards, Pearu From jeremy@zope.com Wed Jun 5 09:22:01 2002 From: jeremy@zope.com (Jeremy Hylton) Date: Wed Jun 5 08:22:01 2002 Subject: [Distutils] updated SF patch In-Reply-To: References: <15612.50124.189533.335448@slothrop.zope.com> Message-ID: <15614.571.896421.263760@slothrop.zope.com> >>>>> "PP" == Pearu Peterson writes: PP> For your information, the module scipy_distutils from the SciPy PP> (www.scipy.org) package extends distutils quite a bit: it PP> provides definitions for a dozen of Fortran 77/90/95 compilers PP> from different vendors, it supports compilation of Fortran PP> sources and building (automatically generated) extension modules PP> to wrap Fortran and C libraries, etc. Thanks for the pointer! I had no idea what kind of extensions people had come up with and it's quite educational (for me at least) to see one. PP> to wrap Fortran and C libraries, etc. To achieve all that many PP> hooks from the standard distutils needed to be extended and I PP> cannot imagine if all that could have be done using just a PP> "small" API (whatever that would be). I guess I don't know what a "small" API would be either. My concern is that an extension could rely on accidents of the current implementation without realizing it. Since there's no documented API, there's no way for an extension writer to know what is intentional and what is accidental. PP> However, I don't know what kind of changes are you planning and PP> therefore I am not sure if they would have any impact to PP> scipy_distutils. I had specifically wondered about all the verbose arguments passed to distutils functions and the announce() method on some objects. I just checked in some changes that effectively ignores the verbose argument, and I wondered if it needed to be preserved at all. I see that the scipy_distutils passes the verbose argument to several functions, so removal of it would affect you. PP> What is the definition of handful people? Do you count extension PP> developers or the users of these extensions? If the later, one PP> would really need lots of hands when considering the current PP> user base of SciPy alone (to give some idea, currently there are PP> more than 100 subscribers to the scipy users mailing list formed PP> in less than one year). I think we would have to consider the users of the extensions, too. (But if you're the only one, we can figure something out .) Jeremy From mal@lemburg.com Wed Jun 5 09:30:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Jun 5 08:30:02 2002 Subject: [Distutils] Fortran compiler (updated SF patch) References: <15612.50124.189533.335448@slothrop.zope.com> <15614.571.896421.263760@slothrop.zope.com> Message-ID: <3CFE03F1.8030807@lemburg.com> eremy Hylton wrote: >>>>>>"PP" == Pearu Peterson writes: >>>>> > > PP> For your information, the module scipy_distutils from the SciPy > PP> (www.scipy.org) package extends distutils quite a bit: it > PP> provides definitions for a dozen of Fortran 77/90/95 compilers > PP> from different vendors, it supports compilation of Fortran > PP> sources and building (automatically generated) extension modules > PP> to wrap Fortran and C libraries, etc. Wouldn't it be a good idea to move some of those into the distutils core ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From pearu@cens.ioc.ee Wed Jun 5 13:09:02 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Wed Jun 5 12:09:02 2002 Subject: [Distutils] updated SF patch In-Reply-To: <15614.571.896421.263760@slothrop.zope.com> Message-ID: On Wed, 5 Jun 2002, Jeremy Hylton wrote: > >>>>> "PP" == Pearu Peterson writes: > > PP> However, I don't know what kind of changes are you planning and > PP> therefore I am not sure if they would have any impact to > PP> scipy_distutils. > > I had specifically wondered about all the verbose arguments passed to > distutils functions and the announce() method on some objects. I just > checked in some changes that effectively ignores the verbose argument, > and I wondered if it needed to be preserved at all. I see that the > scipy_distutils passes the verbose argument to several functions, so > removal of it would affect you. I took a look on your patch and I think as a first step we (in scipy) can remove the usage of verbose arguments from scipy_distutils and start using log facilities so that scipy_distutils would still work with distutils from Python 2.1 and 2.2. And after that, scipy_distutils should be immune to your changes in distutils from Python 2.3. BTW, can Python 2.1,2.2 users later upgrade their distutils or is distutils now inseparable part of the latest Python version? In scipy_distutils we would like to avoid dublicating code with the standard distutils but still support Python versions starting from 2.1. > PP> What is the definition of handful people? Do you count extension > PP> developers or the users of these extensions? If the later, one > PP> would really need lots of hands when considering the current > PP> user base of SciPy alone (to give some idea, currently there are > PP> more than 100 subscribers to the scipy users mailing list formed > PP> in less than one year). > > I think we would have to consider the users of the extensions, too. > (But if you're the only one, we can figure something out .) (I guess by "...figure something out" you mean the possbile changes to scipy_distutils that I mentioned above. But I don't get this , I see it a lot in various python lists but still not sure about its meaning, is it good or bad, or something else. ) Regards, Pearu From pearu@cens.ioc.ee Wed Jun 5 13:14:01 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Wed Jun 5 12:14:01 2002 Subject: [Distutils] Fortran compiler (updated SF patch) In-Reply-To: <3CFE03F1.8030807@lemburg.com> Message-ID: On Wed, 5 Jun 2002, M.-A. Lemburg wrote: > eremy Hylton wrote: > >>>>>>"PP" == Pearu Peterson writes: > >>>>> > > > > PP> For your information, the module scipy_distutils from the SciPy > > PP> (www.scipy.org) package extends distutils quite a bit: it > > PP> provides definitions for a dozen of Fortran 77/90/95 compilers > > PP> from different vendors, it supports compilation of Fortran > > PP> sources and building (automatically generated) extension modules > > PP> to wrap Fortran and C libraries, etc. > > Wouldn't it be a good idea to move some of those into the > distutils core ? Additing Fortran stuff to distutils would mean that somebody must also maintain it. Currently, I think, scipy is most active in using Fortran stuff in Python and therefore ideal also for maintaining these hooks. But on the other hand, Fortran stuff in scipy_distutils is generic in the sense that it can be used in other projects as well (and indeed, scipy_distutils is used separately from scipy already). So, ideal place for Fortran stuff would be in the standard distutils, IMHO. However, there might be some voices against adding Fortran stuff to distutils core. See the thread starting at http://mail.python.org/pipermail/distutils-sig/2001-August/002569.html I would volunteer to work with moving Fortran stuff to distutils provided that it will not be too painful -- due to relatively low interest in Fortran among Python users and developers I am a bit afraid to hit my head against a wall for nothing. Regards, Pearu From mal@lemburg.com Wed Jun 5 14:00:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Jun 5 13:00:02 2002 Subject: [Distutils] Fortran compiler (updated SF patch) References: Message-ID: <3CFE435A.7020909@lemburg.com> Pearu Peterson wrote: > On Wed, 5 Jun 2002, M.-A. Lemburg wrote: > > >>eremy Hylton wrote: >> >>>>>>>>"PP" == Pearu Peterson writes: >>>>>>> >>> PP> For your information, the module scipy_distutils from the SciPy >>> PP> (www.scipy.org) package extends distutils quite a bit: it >>> PP> provides definitions for a dozen of Fortran 77/90/95 compilers >>> PP> from different vendors, it supports compilation of Fortran >>> PP> sources and building (automatically generated) extension modules >>> PP> to wrap Fortran and C libraries, etc. >> >>Wouldn't it be a good idea to move some of those into the >>distutils core ? > > > Additing Fortran stuff to distutils would mean that somebody must also > maintain it. Currently, I think, scipy is most active in using Fortran > stuff in Python and therefore ideal also for maintaining these hooks. > > But on the other hand, Fortran stuff in scipy_distutils is generic in > the sense that it can be used in other projects as well (and indeed, > scipy_distutils is used separately from scipy already). So, ideal > place for Fortran stuff would be in the standard distutils, IMHO. How much code are we talking about here ? > However, there might be some voices against adding Fortran stuff to > distutils core. See the thread starting at > > http://mail.python.org/pipermail/distutils-sig/2001-August/002569.html Paul may be right in the sense that a) Fortran isn't generally used b) the code is too compiler specific > I would volunteer to work with moving Fortran stuff to distutils provided > that it will not be too painful -- due to relatively low interest in > Fortran among Python users and developers I am a bit afraid to hit my > head against a wall for nothing. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From pearu@cens.ioc.ee Wed Jun 5 14:55:02 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Wed Jun 5 13:55:02 2002 Subject: [Distutils] Fortran compiler (updated SF patch) In-Reply-To: <3CFE435A.7020909@lemburg.com> Message-ID: On Wed, 5 Jun 2002, M.-A. Lemburg wrote: > Pearu Peterson wrote: > > > > But on the other hand, Fortran stuff in scipy_distutils is generic in > > the sense that it can be used in other projects as well (and indeed, > > scipy_distutils is used separately from scipy already). So, ideal > > place for Fortran stuff would be in the standard distutils, IMHO. > > How much code are we talking about here ? About 1400LOC in command/{build_flib,run_f2py}.py that are directly related to Fortran support (Fortran compiler definitions, extension generator, etc) plus some additional hooks to glue it with distutils. > > However, there might be some voices against adding Fortran stuff to > > distutils core. See the thread starting at > > > > http://mail.python.org/pipermail/distutils-sig/2001-August/002569.html > > Paul may be right in the sense that > a) Fortran isn't generally used > b) the code is too compiler specific Paul may be also wrong in the sense that a) Fortran is generally used in scientific community. b) What code? In scipy_distutils/command/build_flib.py compiler specific code is well factored considering the number of supported compilers and that scipy_distutils is used both in Unix and Windows platforms. c) I have been in the business of Fortran-Python connection for more than three years and I know the releated issues well but I don't share Paul's pessimism. Considering the current development I can tell that this pessimism was not justified. Regards, Pearu From paul@pfdubois.com Thu Jun 6 00:34:24 2002 From: paul@pfdubois.com (Paul F Dubois) Date: Wed Jun 5 23:34:24 2002 Subject: [Distutils] Fortran compiler (updated SF patch) In-Reply-To: Message-ID: <000001c20d0a$ef3a3ac0$0c01a8c0@NICKLEBY> I don't think what I wrote is incorrect; what I said basically was that Fortran support would have to be done by hand and could not piggy-backed off the Python configuration. I also thought the default compiler flags would be satisfactory for a smaller portion of the files to be compiled than is the case with C. I still think both those things. Remember, I wrote what I wrote at a time when it seemed to me that distutils still needed a lot of work on the C side. However, things have changed now in that there is more manpower available, someone has already done a lot of the Fortran work, and distutils itself is farther along. I think we should proceed. If there had been a certain amount of managed manpower available and I was managing the project, I would have seen to it that the documentation for the C side had more priority than Fortran support. I would have wanted C++ support before Fortran too (I haven't followed developments closely -- is that in now?) I keep wondering too what the relationship with SCons should be. Someone wake up Pearu -- he fainted when I agreed with him. From paul@pfdubois.com Mon Jun 10 14:53:02 2002 From: paul@pfdubois.com (Paul F Dubois) Date: Mon Jun 10 13:53:02 2002 Subject: [Distutils] Question about libraries Message-ID: <000001c210a7$8d8e95f0$0c01a8c0@NICKLEBY> I want to use distutils to build an ordinary C library for subsequent use in other parts of my build. I have a setup file that contains this call to setup: setup (name = "libcmds", ... libraries = [ ('cdms', {'sources': sourcelist, 'macros': macros, 'include_dirs': include_dirs, 'library_dirs': library_dirs, } ), ] This works and I can build the library libcdms.a, but it is put in build/temp.linux-i686-2.2, hardly the kind of place I want to refer to in other parts of my build. Is there a way to install it somewhere? Or get back the name of the library file so that I can move it myself? From florent.rougon@free.fr Mon Jun 10 16:08:01 2002 From: florent.rougon@free.fr (Florent Rougon) Date: Mon Jun 10 15:08:01 2002 Subject: [Distutils] Question about libraries In-Reply-To: <000001c210a7$8d8e95f0$0c01a8c0@NICKLEBY> References: <000001c210a7$8d8e95f0$0c01a8c0@NICKLEBY> Message-ID: <877kl754xn.fsf@florent.hn.org> "Paul F Dubois" wrote: > This works and I can build the library libcdms.a, but it is put in > build/temp.linux-i686-2.2, hardly the kind of place I want to refer to > in other parts of my build. Is there a way to install it somewhere? Or > get back the name of the library file so that I can move it myself? Hi, I use the following shell command for one of my (unofficial) Debian packages: cp "build/lib`python -c \ 'import sys, distutils.util; \ print \".%s-%s\" % \ (distutils.util.get_platform(), sys.version[0:3])'`/_xmms.so" . Not very elegant nor readable, but works for me. The part just after "build/lib" yields the ".linux-i686-2.2" you seem to be looking for. -- Florent From thomas.heller@ion-tof.com Tue Jun 11 11:39:02 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jun 11 10:39:02 2002 Subject: [Distutils] Question about libraries References: <000001c210a7$8d8e95f0$0c01a8c0@NICKLEBY> Message-ID: <003b01c21155$66168740$e000a8c0@thomasnotebook> > I want to use distutils to build an ordinary C library for subsequent > use in other parts of my build. I have a setup file that contains this > call to setup: > > setup (name = "libcmds", > ... > libraries = [ > ('cdms', > {'sources': sourcelist, > 'macros': macros, > 'include_dirs': include_dirs, > 'library_dirs': library_dirs, > } > ), > ] > This works and I can build the library libcdms.a, but it is put in > build/temp.linux-i686-2.2, hardly the kind of place I want to refer to > in other parts of my build. Isn't this directory automatically appended to the library_dirs by distutils? Thomas From paul@pfdubois.com Tue Jun 11 12:13:02 2002 From: paul@pfdubois.com (Paul F Dubois) Date: Tue Jun 11 11:13:02 2002 Subject: [Distutils] Question about libraries In-Reply-To: <003b01c21155$66168740$e000a8c0@thomasnotebook> Message-ID: <000501c2115a$744198a0$0c01a8c0@NICKLEBY> Yes, there would be no problem if I wanted to build the library solely for use in a single invocation of distutils. But I have three separate packages, each with their own setup.py, and they all need to share the same library. > -----Original Message----- > From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > Sent: Tuesday, June 11, 2002 7:37 AM > To: Paul F Dubois; distutils-sig@python.org > Subject: Re: [Distutils] Question about libraries > > > > I want to use distutils to build an ordinary C library for > subsequent > > use in other parts of my build. I have a setup file that > contains this > > call to setup: > > > > setup (name = "libcmds", > > ... > > libraries = [ > > ('cdms', > > {'sources': sourcelist, > > 'macros': macros, > > 'include_dirs': include_dirs, > > 'library_dirs': library_dirs, > > } > > ), > > ] > > This works and I can build the library libcdms.a, but it is put in > > build/temp.linux-i686-2.2, hardly the kind of place I want > to refer to > > in other parts of my build. > > Isn't this directory automatically appended to the > library_dirs by distutils? > > Thomas > From thomas.heller@ion-tof.com Tue Jun 11 13:00:08 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jun 11 12:00:08 2002 Subject: [Distutils] Question about libraries References: <000001c210a7$8d8e95f0$0c01a8c0@NICKLEBY> Message-ID: <008501c21160$c66537d0$e000a8c0@thomasnotebook> > I want to use distutils to build an ordinary C library for subsequent > use in other parts of my build. I have a setup file that contains this > call to setup: > > setup (name = "libcmds", > ... > libraries = [ > ('cdms', > {'sources': sourcelist, > 'macros': macros, > 'include_dirs': include_dirs, > 'library_dirs': library_dirs, > } > ), > ] > This works and I can build the library libcdms.a, but it is put in > build/temp.linux-i686-2.2, hardly the kind of place I want to refer to > in other parts of my build. Is there a way to install it somewhere? Or > get back the name of the library file so that I can move it myself? It seems the directory is available as the 'build_clib' attribute of the 'build_clib' command. You can retrieve it, for example, in your own build_ext command (or maybe better in your install_lib command): from distutils.command import install_lib class my_install_lib(install_lib.install_lib): def run(self): install_lib.install_lib.run(self) build_lib = self.get_finalized_command("build_clib") # now install the clib somewhere else and later: setup(..., cmdclass = {'install_lib': my_install_lib}, ...) Does this help? Thomas From Katy & Steve Lee" This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C2124F.C2FC82C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there a minimal 'runtime' installation. I would like to distribute a = 'product' consisting of Python scripts plus a few other bits by a single = Windows installer that does not require Python to be installed before = and see no reason to insist that the user install the entire python dev = as they are probably not at all interested in it. Oh and another question is - I have a number of .msm (Microsoft = Installer Merge files) files to distribute/install do you know how I = could make these part of a single python installer? Thanks Steve Lee ------=_NextPart_000_004D_01C2124F.C2FC82C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there a minimal 'runtime' = installation. I would=20 like to distribute a 'product' consisting of Python scripts plus a few = other=20 bits by a single Windows installer that does not require Python to be = installed=20 before and see no reason to insist that the user install the entire = python dev=20 as they are probably not at all interested in it.
 
Oh and another question is - I have a = number of=20 .msm (Microsoft Installer Merge files) files to distribute/install do = you know=20 how I could make these part of a single python installer?
 
Thanks
 
Steve = Lee
------=_NextPart_000_004D_01C2124F.C2FC82C0-- From andy47@halfcooked.com Wed Jun 12 20:01:01 2002 From: andy47@halfcooked.com (Andy Todd) Date: Wed Jun 12 19:01:01 2002 Subject: [Distutils] Windows specific installer References: <005001c21247$61de93f0$4e4318d4@fullmeasure1> Message-ID: <3D07D248.8080205@halfcooked.com> Katy & Steve Lee wrote: > Is there a minimal 'runtime' installation. I would like to distribute a > 'product' consisting of Python scripts plus a few other bits by a single > Windows installer that does not require Python to be installed before > and see no reason to insist that the user install the entire python dev > as they are probably not at all interested in it. > > Oh and another question is - I have a number of .msm (Microsoft > Installer Merge files) files to distribute/install do you know how I > could make these part of a single python installer? > > Thanks > > Steve Lee Steve, I suggest you look at either py2exe (http://starship.python.net/crew/theller/py2exe/) or Gordon McMillan's installer (http://www.mcmillan-inc.com/install1.html). Both of these tools package up Python and your application into an executable suitable for distributing to end users. Each has its own strengths and weaknesses so I would suggest you read a little about them and decide which one better suits your requirements. As for the Microsoft files, back to the list I'm afraid ... Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From jeremy@zope.com Thu Jun 13 14:40:17 2002 From: jeremy@zope.com (Jeremy Hylton) Date: Thu Jun 13 13:40:17 2002 Subject: [Distutils] change to compiler implementations In-Reply-To: References: Message-ID: <15624.55417.763429.27404@slothrop.zope.com> I just checked in two sets of changes to distutils. I refactored in the implementation of compile() methods and I added some simple dependency tracking. I've only been able to test the changes on Unix, and expect Guido will soon test it with MSVC. I'd appreciate it if people with other affected compilers (Borland, Cygwin, EMX) could test it. Jeremy From guido@python.org Thu Jun 13 14:57:00 2002 From: guido@python.org (Guido van Rossum) Date: Thu Jun 13 13:57:00 2002 Subject: [Distutils] Re: [Python-Dev] change to compiler implementations In-Reply-To: Your message of "Thu, 13 Jun 2002 13:38:01 EDT." <15624.55417.763429.27404@slothrop.zope.com> References: <15624.55417.763429.27404@slothrop.zope.com> Message-ID: <200206131755.g5DHtED02030@odiug.zope.com> > I just checked in two sets of changes to distutils. I refactored in > the implementation of compile() methods and I added some simple > dependency tracking. I've only been able to test the changes on Unix, > and expect Guido will soon test it with MSVC. I'd appreciate it if > people with other affected compilers (Borland, Cygwin, EMX) could test > it. Um, I don't use setup.py with MSVC on Windows. The MSVC project, for better or for worse, has entries to build all the extensions we need, and I don't have any 3rd party extensions I'd like to build. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas.heller@ion-tof.com Thu Jun 13 15:07:02 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Jun 13 14:07:02 2002 Subject: [Distutils] change to compiler implementations References: <15624.55417.763429.27404@slothrop.zope.com> Message-ID: <0ae001c21304$cb9d0f20$e000a8c0@thomasnotebook> From: "Jeremy Hylton" > I just checked in two sets of changes to distutils. I refactored in > the implementation of compile() methods and I added some simple > dependency tracking. I've only been able to test the changes on Unix, > and expect Guido will soon test it with MSVC. I'd appreciate it if > people with other affected compilers (Borland, Cygwin, EMX) could test > it. > I've tested some of my extensions with MSVC, and it works fine. Thomas From paul@pfdubois.com Thu Jun 13 16:01:02 2002 From: paul@pfdubois.com (Paul F Dubois) Date: Thu Jun 13 15:01:02 2002 Subject: [Distutils] Re: [Python-Dev] change to compiler implementations In-Reply-To: <200206131755.g5DHtED02030@odiug.zope.com> Message-ID: <001101c2130c$8dee5fa0$0c01a8c0@NICKLEBY> Numeric is a suitable stress test on Windows that uses a setup.py. > -----Original Message----- > From: distutils-sig-admin@python.org > [mailto:distutils-sig-admin@python.org] On Behalf Of Guido van Rossum > Sent: Thursday, June 13, 2002 10:55 AM > To: jeremy@zope.com > Cc: python-dev@python.org; distutils-sig@python.org > Subject: [Distutils] Re: [Python-Dev] change to compiler > implementations > > > > I just checked in two sets of changes to distutils. I > refactored in > > the implementation of compile() methods and I added some simple > > dependency tracking. I've only been able to test the > changes on Unix, > > and expect Guido will soon test it with MSVC. I'd appreciate it if > > people with other affected compilers (Borland, Cygwin, EMX) > could test > > it. > > Um, I don't use setup.py with MSVC on Windows. The MSVC > project, for better or for worse, has entries to build all > the extensions we need, and I don't have any 3rd party > extensions I'd like to build. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distut> ils-sig > From pehr@EINK.com Mon Jun 17 12:34:01 2002 From: pehr@EINK.com (Pehr Anderson) Date: Mon Jun 17 11:34:01 2002 Subject: [Distutils] Windows specific installer In-Reply-To: <005001c21247$61de93f0$4e4318d4@fullmeasure1> References: <005001c21247$61de93f0$4e4318d4@fullmeasure1> Message-ID: <1024327960.12582.59.camel@pehr-r30> Hey there, We do exactly as you decribe, turn our python app into a fully self-installing package for windows users that can be installed with just a few clicks. We use a free tool called Inno. It works really well. I did not set up our Inno packaging configuration so I can't answer questions about how to use it (I spend all of my time in Linux). I can verify that Inno works great for packaging and distributing commercial python apps for Windows. Our app uses WXwindows and Inno had no trouble including all the necessary libraries. http://www.jrsoftware.org/isinfo.php ---pehr On Wed, 2002-06-12 at 15:28, Katy & Steve Lee wrote: > Is there a minimal 'runtime' installation. I would like to distribute a > 'product' consisting of Python scripts plus a few other bits by a single > Windows installer that does not require Python to be installed before > and see no reason to insist that the user install the entire python dev > as they are probably not at all interested in it. > > Oh and another question is - I have a number of .msm (Microsoft > Installer Merge files) files to distribute/install do you know how I > could make these part of a single python installer? > > Thanks > > Steve Lee