Allow to change default library.zip name

[CHUK-ANDREW]

library.zip is a default and hard-coded name for Freezed dependencies. This works fine until we need to Freeze two and more python scripts into few binaries, which will be stored into one directory. In this case library.zip will be overwritten and only one binary will keep working. I suggest to change default library.zip name and use binary name (similar to older cx_Freeze versions).

cx_Freeze-6.2.patch.txt

[marcelotduarte]

But cx-freeze can generate more than one executable - For me is the best ;-) In this sample you can see how to do: https://github.com/marcelotduarte/cx_Freeze/blob/master/cx_Freeze/samples/matplotlib/setup.py

[CHUK-ANDREW]

Thank you for answer, but my case is a little bit different. We have setup.py for each application/script. And distribution could be done in different way - some binaries added or removed. Before we used Python 2.7 and cx_Freeze 4 - so we get one binary and one zip, which could be easily moved.

And one more - each script may have its own dependencies, which are not used in other one

[marcelotduarte]

Please read: https://cx-freeze.readthedocs.io/en/latest/development/index.html

[CHUK-ANDREW]

Will prepare pull request for this

[marcelotduarte]

Maybe another approach can do what you want. If you use a setup like this: https://github.com/marcelotduarte/cx_Freeze/blob/master/cx_Freeze/samples/matplotlib/setup_zip.py The difference is: 'zip_include_packages': ["*"], 'zip_exclude_packages': [],

Or, use a different build dir for each executable, see in that example the option: 'build_exe': build_exe_dir

I'm suggesting this, because this change can break others. For me, I use projects with 8 executables, and they share the library.zip, and this reduces the size of the final distribution by a factor of 6.

[CHUK-ANDREW]

I already use 'zip_include_packages': ["*"], 'zip_exclude_packages': [] - helps a lot, but unfortunately its not enough in my case. Also different subdirs wont work for me. I have double check my solution and yes, you was right - it might broke generation more than one executable...

[enkore]

library.zip has to be known to the launcher/bootstrapper/base (see source/bases/common.c, CX_PATH_FORMAT), so you can only change it if you patch and recompile the base. It would of course be possible to extend the bases to support configuration without recompilation (the classic approach is just appending some configuration data to the binary).