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 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. > 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. > 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? Anthony ------------------------------------------------------------------------------ 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
