On 22 February 2010 22:46, Anthony Tuininga <[email protected]> wrote: > On Mon, Feb 22, 2010 at 1:23 PM, Michael Wood <[email protected]> wrote: >> On 22 February 2010 17:41, Kris <[email protected]> wrote: >> [...] >>> I now understand what the executables need to run. But it is still not >>> clear to me how to distribute the executables and libraries together. >>> >>> For example, the build files contain libpython3.1.so.1.0. Clearly, this >>> is the python library and should be distributed. But it definitely >>> shouldn't be distributed in /usr/lib (e.g. as part of a .rpm), since it >>> would conflict with a packaged version of python. On the other hand, one >>> needs to guarantee that this library will be available, else the built >>> executables won't run: "somehow" libpython3.1.so.1.0 needs to be >>> distributed. >>> >>> So, where should the .so files be installed ? >> [...] >> >> I think this depends on who you are targeting. If you want to target >> a particular Linux distribution then it's easy. Just specify >> dependencies on Python and the other packages you need and do not > > True. But if you are going to add dependencies on these items in the > target distribution the question would immediately arise as to why you > would be using cx_Freeze at all? Shipping the scripts for your
Good point. > application would by far be the simplest and is not something that > cx_Freeze attempts to cover in any way. Shipping binaries would not be > that helpful in this situation. You can do so by specifying that you > don't want to copy any dependencies when building the frozen > executable. This will assume the presence of Python on the target > machine with all of the dependencies your application requires -- but > I can't see much benefit to this approach (over shipping your code > directly) other than obfuscating the source. Yes, I agree. >> bundle them. Things become more tricky when you want to target >> various different distributions, perhaps with different package >> management systems, and maybe older distributions that don't have a >> Python 3.x package etc. > > This was the original point of cx_Freeze -- creating an executable > that can run without requiring Python or any of its dependencies > installed on the target system. Yes, I suppose I was just trying to say that creating a package for a particular distribution vs. something that can run on any distribution without other dependencies are quite different things and should probably be done in different ways. >> Probably the safest way is to dump everything under >> /usr/lib/your-package or somewhere similar, which is basically what >> cx_Freeze apparently does (I have only used it under Windows so far). >> But this would not be the way to get your package into the official >> Fedora/Ubuntu/whatever repositories. > > Are you referring to cx_Freeze itself or the hypothetical application > packaged using cx_Freeze? In any case, what would you suggest or what > do you see as the potential problems that would need to be resolved? I mean that a something packaged using cx_Freeze is (according to your e-mail earlier in the thread) bundled into /usr/lib/something or /usr/local/lib/something with all the dependencies and that this is the safest way to do it so that it works with multiple distributions, but that if you want to have your (hypothetical) software (not cx_Freeze) included in Fedora/Ubuntu/whatever then this is not the way to go. Sorry for the confusion :) -- Michael Wood <[email protected]> ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ cx-freeze-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cx-freeze-users
