Julia: make compilation-related CLI option names less confusing

Created on 31 Jul 2017  Â·  9Comments  Â·  Source: JuliaLang/julia

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}.

precompile

Most helpful comment

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.

All 9 comments

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.

  • The --precompile option could be called --use-sysimg-native-code={yes,no} or some such (a bit long but it's rarely used).
  • The --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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

omus picture omus  Â·  3Comments

iamed2 picture iamed2  Â·  3Comments

m-j-w picture m-j-w  Â·  3Comments

TotalVerb picture TotalVerb  Â·  3Comments

wilburtownsend picture wilburtownsend  Â·  3Comments