More flexible location arguments for output

[giokara-oqton]

We are using Nuitka within the Bazel ecosystem. See a very basic example in https://github.com/giokara-oqton/nuitka-under-bazel. Bazel by default works with sandboxed environments and has a strict interpretation of where output files are written. The way that Nuitka allows to define where outputs are generated are not completely compatible with Bazel.

• --output-filename does not allow to provide a filepath, only the name of the file
• --output-dir does allow to provision a path. This is what is currently used. But getting the right directory is not simple in the Bazel approach. We currently use this approach but hardcode the part of the path that cannot easily be obtained, which makes it in turn less generic when using on multiple platforms or even when using different build options in Bazel.

Of course this can be easily (or less easily) be circumvented by writing custom scripting in Bazel around the actual Nuitka call. Therefore this is more meant as a niche user feedback with the hope of ever getting one of below features to more flexibly deal with this issue in Bazel:

• Allow --output-filename to contain a full path or relative path from CWD. This makes it very simple to resolve the issue since it would allow to directly define the path using Bazel's location Makefile-like expansion.
• Allow to provide some means to do post-processing, in order to allow copying the final executable to the right location.

[kayhayen]

You are misunderstanding the purpose of --output-filename, which you are not supposed to use unless you have specific needs.

This is its description:

Specify how the executable should be named. For extension modules there is no
choice, also not for standalone mode and using it will be an error. This may
include path information that needs to exist though.

As Python has a fixed idea of what extension modules must be called, there is not as much flexibility. And also, this influences the name inside of the standalone distribution, but not the folder name, but the onefile binary name, if used. It's complicated.

This is why Nuitka goes with specifying an output folder and applying defaults for the filenames (unless legally overridden) and I do not really fancy adding onefile specific behaviour of --output-filename which then must know how to interact with --output-dir. Maybe if the temporary directories were split into a separate option.

Plugins can do post-processing with various stages. Using onFinalResult means you get the path produced in whatever mode, and Nuitka is not going to do much more than reporting and running it if asked.

This is terribly complex stuff and I do not see myself touching it in the near future myself. But if somebody were to make all use cases continue to work well, catch all the possible user errors with the new behaviour, I would be fine, but I don't see it happening.