From: David B. <db...@fi...> - 2004-12-29 20:40:28
|
Thomas Heller [mailto:th...@py...] writes: > py2exe uses a a tempoary build directory which is used to collect the > pyc files that are needed for the final executable. Thanks, I just figured this out too after pruning my working directory had no impact (and I feel somewhat stupid for not at least thinking of the distutils build tree). > This directory > isn't cleaned after running the setup script, so it will probably > eventually contain all the pycs from all your applications. You should > remove it before running the next setup. This is an artifact of > distutils, probably, and maybe it would be better to remove it > automatically. Or even if not automatically, I was hoping that a distutils "clean" operation would clear it out, but it doesn't appear to (perhaps there's no easy way to tie into the clean operation?). But now that I know what to blow away, it's not a terrible burden. > The downside of this would be that if your setup script does not only > specify the py2exe stuff but also other packages needed by your exe the > compiled extensions would be recompiled on each run. True. One thing I was wondering about - the build tree is already equipped to handle multiple targets and things, and since py2exe is in control of the collection tree (e.g., it sets the "winexe" root), couldn't it make the root include the target name? That would keep my multiple applications distinct for collection/temporary file purposes. Of course, I don't know if the common use of "winexe" might be what gives you the "build multiple exes sharing the same library.zip" behavior, or if it just enables the same net result even if you have separate targets in your setup rather than multiple scripts in a single target. Actually, if there was just a small change to let the root name be an option (defaulting to independent directories for better isolation would be nice, but you might have to default to the existing winexe for backwards compatibility), then the setup file could control which targets shared the same library.zip by just setting up appropriate sharing of the root name. Presumably you could then have a single setup that build different collections of targets with different shared libraries. -- David |
From: David B. <db...@fi...> - 2004-12-30 19:45:06
|
> Hm, single setup with multiple collections is not what I need now. > And multiple setup with shared collections is what you want, if I > understand correctly. Actually, in my particular case, all I'm really looking for is per-setup file independence (e.g., processing two distinct setup files in the same working directory shouldn't share anything). The stuff talking about the shared collections files in a common directory - the stuff about the shared collections was my attempt to discuss a change that would permit maintaining existing behavior, which I understand to be a single target in a single setup file specifying multiple executables that share a collection (I'm not sure if current behavior also supports multiple targets in a single setup file or not). > I've made a small path which includes the zipfile name in the directory > used to collect all the .pyc or .pyo files. Maybe this does what you > need? In my case I'd probably conditionalize it on the destination directory since my independent setups all output to different directories so I can then package up the executable with Inno Setup. (Using separate libraries wouldn't help with the extension modules) But having a specific option that just set the collection directory would cover both use cases and leave it up to the setup file, without involving the existing zipfile or destination directory options. Since I'm not sure I'm explaining this well, I can probably work up a patch that at least exhibits the behavior I'm aiming for if only as the best way to describe it. > Still, if you first build non-optimized, then optimized, .pyc plus .pyo > files would be included. I had another version which cleans out files > before building the archive, but that wouldn't allow the cross-setup > script operation. Alternatively you could just track the actual files that were collected and ignore others in the collection directory, but that would also have issues when you specifically wanted independent setups to share collections. Although I suppose that if someone were to explicitly request sharing (say by setting both setups and/or targets to use the same collection name), then isn't unreasonable to expect them to understand that if their setup definitions created two compiled versions of some files that they will get both versions in the output. Otherwise, you end up with the general question of how to fill in a matrix with dimensions of single/multiple setup.py, single/multiple targets within the setup, and single/multiple generated files per target, with each grid location needing to control what is shared. But that probably feels like overkill. -- David |
From: Thomas H. <th...@py...> - 2004-12-30 20:21:14
|
>> Still, if you first build non-optimized, then optimized, .pyc plus .pyo >> files would be included. I had another version which cleans out files >> before building the archive, but that wouldn't allow the cross-setup >> script operation. > > Alternatively you could just track the actual files that were > collected and ignore others in the collection directory, but that > would also have issues when you specifically wanted independent setups > to share collections. Yes, and that's what I will do. Sharing .py[co] collections between multiple setup scripts is probably not a good idea. The 'collect' directory will only be a storage place for compiled files, and the collection will only contain files that were collected in this particular run of setup.py. This should also satisfy your need, IIUC. Thanks for the input, Thomas |
From: Thomas H. <th...@py...> - 2004-12-30 18:46:19
|
> One thing I was wondering about - the build tree is already > equipped to handle multiple targets and things, and since py2exe is in > control of the collection tree (e.g., it sets the "winexe" root), > couldn't it make the root include the target name? That would keep my > multiple applications distinct for collection/temporary file purposes. > > Of course, I don't know if the common use of "winexe" might be what > gives you the "build multiple exes sharing the same library.zip" behavior, > or if it just enables the same net result even if you have separate targets > in your setup rather than multiple scripts in a single target. > > Actually, if there was just a small change to let the root name be an > option (defaulting to independent directories for better isolation > would be nice, but you might have to default to the existing winexe > for backwards compatibility), then the setup file could control which > targets shared the same library.zip by just setting up appropriate > sharing of the root name. Presumably you could then have a single > setup that build different collections of targets with different > shared libraries. Hm, single setup with multiple collections is not what I need now. And multiple setup with shared collections is what you want, if I understand correctly. I've made a small path which includes the zipfile name in the directory used to collect all the .pyc or .pyo files. Maybe this does what you need? It allows sharing this directory for several setup scripts in the same dir, when they use the same name for the zipfile. Additionally I included the Python version as well, this prevents inclusion of compiled files from the wrong python version. Still, if you first build non-optimized, then optimized, .pyc plus .pyo files would be included. I had another version which cleans out files before building the archive, but that wouldn't allow the cross-setup script operation. Thomas Here's the patch: Index: build_exe.py =================================================================== RCS file: /cvsroot/py2exe/py2exe/py2exe/build_exe.py,v retrieving revision 1.41 diff -c -r1.41 build_exe.py *** build_exe.py 18 Nov 2004 17:02:11 -0000 1.41 --- build_exe.py 30 Dec 2004 18:18:18 -0000 *************** *** 323,329 **** bdist_base = self.get_finalized_command('bdist').bdist_base self.bdist_dir = os.path.join(bdist_base, 'winexe') ! self.collect_dir = os.path.abspath(os.path.join(self.bdist_dir, "collect")) self.mkpath(self.collect_dir) self.temp_dir = os.path.abspath(os.path.join(self.bdist_dir, "temp")) --- 323,333 ---- bdist_base = self.get_finalized_command('bdist').bdist_base self.bdist_dir = os.path.join(bdist_base, 'winexe') ! ! ! name = self.distribution.zipfile or "zipfile" ! dirname = "%s\\%d.%d" % (name, sys.version_info[0], sys.version_info[1]) ! self.collect_dir = os.path.abspath(os.path.join(self.bdist_dir, dirname)) self.mkpath(self.collect_dir) self.temp_dir = os.path.abspath(os.path.join(self.bdist_dir, "temp")) |