If you don't already know what they mean (and it's easy to forget even if you once did), the names of these options to julia
are entirely unhelpful and generally actively confusing:
--precompiled={yes|no}
– no, this has nothing to do with module precompilation--compilecache={yes|no}
– but this does! :trollface:--compile={yes|no|all|min}
– I have no idea what this does, despite reading julia --h
Changing --precompiled
to ~--compile-sysimg
~ (see below) --use-sysimg={yes,no}
and --compilecache
to --compile-modules={yes,no}
would make a lot more sense. I would also assume that these control where the julia
processes STDOUT goes:
--output-o name Generate an object file (including system image data)
--output-ji name Generate a system image data file (.ji)
--output-bc name Generate LLVM bitcode (.bc)
--output-incremental=no Generate an incremental output file (rather than complete)
That, of course, is not what they do, but ¯\_(ツ)_/¯. See also https://github.com/JuliaLang/julia/issues/15864 – having --output-x
options control compiler artifacts would make sense for a julia-compile
program, but not for julia
itself. Changing these to --compile-output-format={o,ji,bc}
would be better and maybe --compile-incremental={yes,no}
.
Changing
--precompile
to--compile-sysimg
This one is whether or not the precompiled sysimg gets loaded - it's already been compiled when Julia was built, rather than having to do with compilation that happens at runtime
I think the fact that I didn't know what it does despite the option name and reading the help output really just proves my point. In that case it should be called --use-sysimg
or something.
We might also want to make the use of dashes more consistent. Right now we have machinefile
vs history-file
, compilecache
vscode-coverage
, handle-signals
vs depwarn
.
If we do #15864, then --output-x
and --compile
options are compilation-only, so would not need to necessarily change names.
--precompile
option could be called --use-sysimg-native-code={yes,no}
or some such (a bit long but it's rarely used).--compilecache
option could be called --use-compiled-modules={yes,no}
.--precompile
is probably --compile=jit-all
--compilecache=no
is perhaps just -e 'empty!(Base.LOAD_CACHE_PATH)'
--compilecache=no
is perhaps just-e 'empty!(Base.LOAD_CACHE_PATH)'
Does that error if it tries to write one, skip silently, or skip with a message?
The --compile
options tell the compiler what to do. --precompiled
means to use existing native code from the system image. In theory, they're completely orthogonal.
--compilecache=no is perhaps just -e 'empty!(Base.LOAD_CACHE_PATH)'
It shouldn't be coupled to that implementation though.
Conclusion: for now we should hide (remove from -h
output) the --compile and --output options.
Most helpful comment
We might also want to make the use of dashes more consistent. Right now we have
machinefile
vshistory-file
,compilecache
vscode-coverage
,handle-signals
vsdepwarn
.