是否在所有选项中显示原始命令
Create an importable binary extension module executable instead of a program. Default is off.
Enable standalone mode for output. This allows you to transfer the binary to other machines without requiring an existing Python installation. This also means it will become very large.
It will enable these options: "--follow-imports" and "--python-flag=no_site".
Enable onefile mode on top of standalone mode. This means that instead of a folder, a compressed executable is created and used.
Whether to use the debug version. Default is the version you're running Nuitka with, which is likely a non-debug version. For debug and test purposes only.
Mode used for compilation
Python flags to use. Default is what you used to run Nuitka, this enforces a specific mode. These are also the options present in the standard Python executable.
When compiling with Python 3.4, provide a Python binary path to use for Scons. Otherwise, Nuitka can use the Python you're running Nuitka with,
or find Nuitka installation on its own, e.g. from Windows registry. On Windows, Python 3.5 or higher is required, on non-Windows, Python 2.6 or Python 2.7 is also acceptable.
If specified only once (like --main="1.py"), this will replace the positional argument, which is the file name to compile (entry point).
If specified multiple times (like --main="1.py" --main="2.py"), it will enable "multidist", which allows you to create binaries that depend on the file name or call name.
(Allows multiple main programs to use the same compilation parameters)
For already compiled extension modules, where there is both source code and an extension module, usually the extension module is used, but for best performance, it's better to compile modules from available source code.
If this is not needed, you can use --no-prefer-source-code to disable warnings about this. Default is off.
Include the whole package. Specified in Python namespace form, e.g. 'some_package.sub_package',
Nuitka will then find it and include it and all modules found below that disk location, and make it available for import by the code.
To avoid unwanted subpackages, e.g. tests, you can do '--nofollow-import-to=*.tests'. Default is empty.
(Note: Inclusion here means compiling the included package or module into the binary file and making it importable by the code, not as a dependency)
Include a single module. Specified in Python namespace form, e.g. 'some_package.some_module', then Nuitka will find it and include it in the binary or extension module it creates,
and make it available for import by the code. Default is empty
Include also the code found in the directory, treating them as if they were each a main file. This will override other include options.
You should prefer the other include options. They find things by name rather than by filename, which these options can do through finding stuff in 'sys.path'.
This option is only for very special use cases. Can be given multiple times. Default is empty.
Include files matching PATTERN. Overrides all other follow options. Can be given multiple times. Default is empty
Force recompilation of extension modules from source code. Allows fine-grained control over which extension modules to recompile using name patterns.
Useful when you want to ensure certain modules are compiled from source for better optimization. Can be given multiple times. Default is empty.
Import all imported modules. Enabled by default in standalone mode, otherwise off
Don't recurse into any imported modules at all, this will override all other inclusion options, and cannot be used for standalone mode. Default is off.
Also follow imports into modules from the standard library, which will greatly increase compile time, and is currently not well tested, and may sometimes not work correctly. Default is off.
Follow import to that module if used, or if a package to the whole package. Can be given multiple times. Default is empty.
Do not follow import to that module name even if used, or if a package name, to the whole package, regardless of used. This overrides all other options.
This can also include patterns, e.g. "*.tests". Can be given multiple times. Default is empty.
When creating a onefile, disable compression of the payload. This is mainly for debugging purposes or to save time. Default is off
When creating a onefile, use an archive format that can be unpacked with "nuitka-onefile-unpack" rather than a stream that only the onefile program itself can unpack.
When creating a onefile, on some platforms (currently Windows if not using a cached location) by default a DLL rather than an executable is used to store Python code.
Enabling this option makes the unpacked files use an executable in that case too. Default is off.
This mode is inferred from the specification you use.
If it contains runtime dependent paths, "auto" resolves to "temporary", which will ensure the unpacked binary is deleted after execution,
while "cached" will not delete it, and reuse its contents for a faster startup time next time.
In onefile mode, use this as the folder to unpack to
Using a string like '///' is a good static cache path, and it will not be deleted.
When terminating the child process, e.g. due to CTRL-C or closing, etc., Python code gets a "KeyboardInterrupt" which it might handle for things like flushing data, etc.
This is the amount of time before killing the child hard. Units are milliseconds, default is 5000.
Include data files of given package name. DLLs and extension modules are not data files and not included like this.
File name patterns can be given as well, see below.
By default, data files of packages are not included, but can be through package configuration.
This will only include non-DLLs, non-extension modules, i.e. actual data files. After a ":", optionally a filename pattern can be given, to only select matching files.
Examples: "--include-package-data=package_name" (all files)
"--include-package-data=package_name:*.txt" (only specific types)"
--include-package-data=package_name:some_filename.dat" (specific file).
Default is empty
Include data files by file name. There are many allowed forms.
Use --include-data-files=/path/to/file/.txt=folder_name/some.txt', it will copy one file, if it's more than a dozen files, you'll get an error.
Use '--include-data-files=/path/to/files/.txt=folder_name/' to put all matching files into that folder.
For recursive copying, there is a form with 3 values: '--include-data-files=/path/to/scan=folder_name=/**/*.txt', which keeps the directory structure of the files.
Default is empty.
Include data files from complete directory in the distribution. This is recursive.
If you want non-recursive inclusion, look at '--include-data-files' with patterns.
For example, '--include-data-dir=/path/some_dir=data/some_dir', for plain copy of an entire directory.
All non-code files will be included, and you can also use '--noinclude-data-files' options to remove them.
Default is empty
Do not include data files matching the given filename form. This is against target file name, not source path.
So to exclude a file pattern from 'package_name' package data, it should match as "package_name/*.txt",
or for a whole directory just use "package_name". Default is empty
Include the specified data file pattern in the external part of the onefile binary rather than the internal. This option only makes sense for '--onefile' compilations.
The file has to be specified to be included in some way first, then this option will reference the target path in the distribution. Default is empty.
Output the data files found for the given package name. Default does not execute
Include raw directory in the distribution. This is recursive. Check '--include-data-dir' for the proper option to use. Default is empty.
Output all distribution metadata and their details. Default does not execute.
Include metadata information for the given distribution name. Some packages check for the presence of metadata, version, entry points, etc., and without this option given, it only works if detected at compile time, which doesn't always happen.
Of course, this only makes sense for packages included in the compilation. Default is empty.
Do not include DLL files matching the given filename pattern. This is against target filename, not source path.
So, to ignore a DLL "someDLL" included in the "package_name" package, it should be matched as "package_name/someDLL.*".
Default is empty.
Output the DLLs found for the given package name. Default does not execute.
Output the EXE files found for the given package name. Default does not execute.
Enable warnings for implicit exceptions detected at compile time.
Enable warnings for unusual code detected at compile time.
Allow Nuitka to download external code when needed. For example dependency walker, ccache, or even gcc on Windows. To disable, redirect input from nul device.
For example "</dev/null" or "<NUL:". Default prompts on download.
Disable warnings for the given mnemonic. These are there to ensure you know about certain topics, and typically point to the Nuitka website. Mnemonic is the part at the end of the URL, without the HTML suffix. Can be given multiple times and accepts shell patterns. Default is empty.
Execute immediately the created binary (or import the compiled module). Default is off.
Execute in a debugger (e.g. "gdb" or "lldb") to automatically get a stack trace.
The debugger name will be automatically chosen unless specified via the NUITKA_DEBUGGER_CHOICE environment variable.
Default is off.
Choose a specific debugger to use with the --debugger option. This allows you to specify arbitrary debuggers instead of relying on automatic detection.
For example: gdb, lldb, or any custom debugger. Default is automatic selection.
Ensure absolute compatibility with CPython. Do not allow even the slightest deviation from CPython behavior, e.g. not having better tracebacks or exception messages.
These behaviors are not actually incompatible, only different or worse. This is only for testing, and should not be used.
User provided YAML file with package configuration. You can include DLL files, remove redundancy, add hidden dependencies. Consult the Nuitka package configuration manual
for the full format usage information. Can be given multiple times. Default is empty.
Select what value to use for "__file__". The created binaries and modules "at runtime" (i.e. the default for standalone binaries and module mode) use their own location
to deduct "__file__" value. Included packages pretend to be in directories below that location. This allows putting data files in that location.
If it's just for acceleration, it's better to use "original" value, where the source files location will be used. That is, use the source file locations. With "frozen",
a symbolic "<frozen module_name>" will be used. For compatibility reasons, the "__file__" value will always have a ".py" suffix, no matter what its actual value is.
Select what value to use for "__name__" and "__package__". Using "runtime" (the default for module mode) created modules use the package
to infer the value of "__package__" for full compatibility. "original" values (the default for other modes) allow more static optimization, but are incompatible for those modules
that normally can be loaded into any package.
Remove the build folder after generating the exe or module file. Default is off.
Do not create a ".pyi" file for extension modules created by Nuitka for detecting implicit imports. Default is off.
When creating '.pyi' files for extension modules created with Nuitka, do not use stubgen.
They expose your API, but stubgen can cause issues. Default is off
Specify the name of the executable. Extension modules and standalone mode don't use this, and will report an error if used. This may include existing path information.
Default is "<program_name>.exe" on the current platform
Specify where to put the intermediate and final output files. The selected directory will contain build folders, distribution folders, binary files, etc. Default is the current directory.
Disable code that makes finding compatibility issues easier. For example, this will prevent execution with '-c' arguments, which might be used by code attempting to run the module
and might cause the program to restart itself repeatedly. Once you deploy to end users, disable it, this is helpful in the development process to find typical issues.
Default is off.
Keep deployment mode, but selectively disable features. Deployment mode errors will output these identifiers. Default is empty
Force the environment variable to the given value. Default is empty.
Executing all self checks possible to find errors in Nuitka, do not use for production.
Default is off.
Disable the checks usually done with "--debug". For Python 3.12 and above, do not check for assumptions on known immortal objects.
Some C libraries violate them. If "--debug" is enabled, by default they are checked.
Disable the checks usually done with "--debug".
C compilation may produce warnings, which for some packages is typically not a problem, especially for unused values.
Keep debug information in the generated object files to better interact with a debugger. Default is off.
Enable vmprof based performance profiling. Currently not usable. Default is off.
Trace execution and output it. Output the code lines before executing them. Default is off.
Try to use less memory by reducing the forking of C compilation tasks and using memory-saving options. For embedded machines. Use when you encounter out of memory problems. Default is off.
Generate only C source code, do not compile to binary or module. This is for debugging and code coverage analysis and will not waste CPU. Default is off.
Don't think you can use this directly.
Write the internal program structure and optimization results in XML form to the given filename.
Use features declared as 'experimental'. If there are no experimental features in the code, this may have no effect.
Use secret option labels for each experimental feature (check source code).
Create a new virtual environment in a non-existing path based on the given report file, e.g. '--report=compilation-report.xml'. Default does not execute.
Report warnings about code helpers attempted but not existing.
This helps identify optimization opportunities through better type knowledge. Default is False.
Report warnings about imports that could be trusted but currently are not. This is to identify opportunities to improve the handling of hard modules,
which sometimes can allow for more static optimization. Default is False.
This is not incremental compilation, only for Nuitka development. Recompile already existing files to C. Allows compiling edited C files for quick debugging of generated source code.
For example, to check if the code passes, output values, etc. Default is off. The files it looks at depend on the Python source code to compile.
Create internal graph of the optimization process, don't use for whole programs, only for small test cases. Default is off.
Force the use of clang. On Windows, this requires a working Visual Studio version to support it. Default is off.
Force the use of MinGW64 on Windows. Default is off, unless MSYS2 and MinGW Python are used.
Use link time optimization (MSVC, gcc, clang). Allowed values are "yes", "no", and "auto" (known to work). Default is "auto".
Use Python's static library. Allowed values are "yes", "no", and "auto" (known to work). Default is "auto".
Force the use of specific MSVC version on Windows. Allowed values are "14.3" (MSVC 2022) and other MSVC version numbers.
Use "list" to get a list of installed compilers, or use "latest". Default is to use the latest MSVC if available. Otherwise use MinGW64.
Specify the number of parallel C compiler jobs to use. Negative values indicate the number of CPUs in the system minus that value.
By default, all CPUs of the system are used unless low memory mode is enabled; in low memory mode, the default is 1.
This option is specific to gcc. Select "cf-protection" mode for the gcc compiler. The default value "auto" is to use gcc's default, but you can override it,
e.g. with the value "none" to disable it. See gcc documentation for "-fcf-protection" for details
Don't attempt to use ccache (gcc, clang, etc.) or clcache (MSVC, clangcl). Same effect as --disable-cache=ccache.
Disable dependency analyzer cache. This will cause much longer times to create distribution folders, but can be used if you suspect the cache is causing errors.
Same effect as --disable-cache=dll-dependencies.
Used to update the dependency analyzer cache. This will cause much longer times to create distribution folders, but can be used if you suspect the cache is causing errors or the cache needs to be updated.
Disable selected caches, set "all" for all caches. Currently allowed values are: "all", "ccache", "bytecode",
"compression", "dll-dependencies".
Can be given multiple times or values separated by comma. Default is none.
Clean the given cache before execution, set "all" for all caches. Currently allowed values are:
"all", "ccache", "bytecode", "compression", "dll-dependencies".
Can be given multiple times or values separated by comma. Default is none.
Enable C level profile guided optimization (PGO) by first doing an analysis, and then feeding back the result into the C compilation.
Note: This is experimental and not yet working with Nuitka's standalone mode. Default is off.
Arguments to pass when doing profile guided optimization (PGO). These arguments are passed to the specially built executable during PGO analysis runs. Default is empty.
Command to execute when collecting profile information. Only use this if you need to launch it through a prepared script. Default is to use the created program.
Report data in a way that is comparable, i.e. no time or memory usage values that change with the runs. Default is off.
Disable all information output, but show warnings. Default is off.
Run the C build backend Scons with verbose information, showing the commands executed, and detailed information about the detected compiler. Default is off.
Disable progress bar. Default is off.
Deprecated: Provide progress information and statistics. Disables normal progress bar. Default is off.
Show memory usage. Default is off.
Deprecated: You should use '--report' file instead. Provide information about included modules and DLLs. Default is off.
Output details of actions taken, especially in the optimization process, it may produce a lot of output. Default is off.
Report details of modules, data files, compilation, plugins, etc. in an XML output file. This is also very useful for reporting issues.
For example, these reports can be used to easily rebuild environments with '--create-environment-from-report', but they contain a lot of information. Default is off.
Filename to output '--show-modules' to, should be a filename. Default is standard output.
Filename to output '--verbose' to, should be a filename. Default is standard output.
Report data from yourself. This can be given multiple times, and can be any form of "key=value", where key should be an identifier,
e.g. use "--report-user-provided=pipenv-lock-hash=64a5e4" to track some input value. Default is empty.
Report through a template. Needs template and output filename given "template.rst.j2:output.rst". For built-in templates, check the user manual.
Can be given multiple times. Default is empty.
Force program's standard output to go to this location. Useful for programs with disabled console and programs using the Windows Service plugin of Nuitka commercial. Default is not active,
e.g. use '.out.txt', which is a file near the program, see user manual for a complete list of available values.
Force program's standard error to go to this location. Useful for programs with disabled console and programs using the Windows Service plugin of Nuitka commercial. Default is not active,
e.g. use '.err.txt', which is a file near the program, see user manual for a complete list of available values.
Request Windows User Account Control (UAC) to grant administrator rights when executing. (Windows only). Default is off.
Request Windows User Account Control (UAC) privileges for UI access, for running in certain folders and remote desktop access. (Windows only). Default is off.
Select console mode to use, default mode is force
When compiled as onefile for Windows, display this image while the application is loading. Default is off.
Add executable icon. Can be given multiple times for different resolutions or files containing multiple icons. When selecting a file with multiple icons,
you may also specify a specific icon to use and ignore all others using the #<n> suffix, where n is an integer index starting from 1
Copy icon from this existing executable (Windows only).
When compiling for macOS, create a bundle rather than a plain binary application. This is the only way to disable console, get high DPI graphics, etc., and will enable standalone mode. Default is off.
When signing for notarization, use the proper TeamID identity from Apple, using required runtime signing options so it can be accepted.
Application mode for the application bundle.
What architecture this program should run on. The default value and limitation is what running Python allows. Default is "native", which is the architecture Python runs with.
Add icon for the application bundle. Can be given only once. Default is the Python icon.
Application name to use for macOS signing. For best results, follow the naming format "com.YourCompany.AppName",
as these names must be globally unique, and protected API access might be granted.
Product name to use in the macOS bundle information. Default is the base filename of the binary.