Julia: separate `julia-compile` from `julia`

[StefanKarpinski]

At this point it makes sense to separate julia into an interactive julia which runs scripts and starts the REPL and julia-compile which provides various bootstrapping and compilation features. The basic usage of julia-compile should be julia-compile program.jl which should produce an executable called program which, when run behaves the same way that julia program.jl would. In more advanced modes, it can behave like the current julia --compile=all, etc. Let's use this issue to discuss the desired API and how to split up the options.

[StefanKarpinski]

Straw man separation of flags (now updated).

Common (julia and julia-compile):

 -v, --version             Display version information
 -h, --help                Print this message

 -J, --sysimage <file>     Start up with the given system image file
 --precompiled={yes|no}    Use precompiled code from system image if available
 --compilecache={yes|no}   Enable/disable incremental precompilation of modules
 --handle-signals={yes|no} Enable or disable Julia's default signal handlers

 -C, --cpu-target <target> Limit usage of cpu features up to <target>
 -O, --optimize={0,1,2,3}  Set the optimization level (default 2 if unspecified or 3 if specified as -O)

 --inline={yes|no}         Control whether inlining is permitted (overrides functions declared as @inline)
 --check-bounds={yes|no}   Emit bounds checks always or never (ignoring declarations)
 --math-mode={ieee,fast}   Disallow or enable unsafe floating point optimizations (overrides @fastmath declaration)

 --depwarn={yes|no|error}  Enable or disable syntax and method deprecation warnings ("error" turns warnings into errors)

 --code-coverage={none|user|all}, --code-coverage
                           Count executions of source lines (omitting setting is equivalent to "user")
 --track-allocation={none|user|all}, --track-allocation
                           Count bytes allocated by each source line

Interactive only (julia):

 --startup-file={yes|no}   Load ~/.juliarc.jl
 -f, --no-startup          Don't load ~/.juliarc (deprecated, use --startup-file=no)
 -F                        Load ~/.juliarc (deprecated, use --startup-file=yes)

 -e, --eval <expr>         Evaluate <expr>
 -E, --print <expr>        Evaluate and show <expr>
 -P, --post-boot <expr>    Evaluate <expr>, but don't disable interactive mode (deprecated, use -i -e instead)
 -L, --load <file>         Load <file> immediately on all processors

 -p, --procs {N|auto}      Integer value N launches N additional local worker processes
                           "auto" launches as many workers as the number of local cores
 --machinefile <file>      Run processes on hosts listed in <file>

 -i                        Interactive mode; REPL runs and isinteractive() is true
 -q, --quiet               Quiet startup (no banner)
 --color={yes|no}          Enable or disable color text
 --history-file={yes|no}   Load or save history
 --no-history-file         Don't load history file (deprecated, use --history-file=no)

Compilation only (julia-compile):

 --compile={yes|no|all|min}Enable or disable JIT compiler, or request exhaustive compilation
 --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)

[tkelman]

I think -J is needed for both? handle-signals might be too?

[JeffBezanson]

Yes I think -J is needed for both. However if julia-compile were designed to always "start from zero" then it would actually only be needed by julia. I don't know whether that's a good idea or not.

--track-allocation and --code-coverage are probably also needed by both, for building instrumented binaries.

[StefanKarpinski]

After some more input, we can post another version with options moved around to where they should be.

[StefanKarpinski]

Updated to reflect feedback.

[sfchen]

Will julia-comiple be able to make a stand-alone executable binary, which can run even without julia installed?

[Tetralux]

Is there any progress or further thoughts on this? Presumably still pending?

I'd also like to note that when Julia has the ability to produce executables, it should probably also be able to produce dynamic libraries; Go has an issue with this as there would be multiple GC instances - in Go's case, they would all attempt to use the same storage area, and trample over each other, last I looked.
I'd like to draw attention to this so that it can be designed for better.
Ideally, the DLL would essentially defer its memory management to the parent process in some way so that you don't end up with several GC instances; one for each Julia DLL a program loads!
Even if it wouldn't hurt CPU time that much _[to have multiple GC instances]_, it would presumably be simpler to design if there was only one--and reason about. Especially, in more real-time applications where every sub-millisecond matters. >)

[ablekh]

@StefanKarpinski Just ran across this issue. Good idea, in general. But why a separate command? I would suggest keeping julia command a single interaction point for a better developer UX. Meaning that julia and julia XYZ.jl commands would start relevant interactive Julia sessions (empty and with module XYZ loaded), whereas julia -c [rest of the arguments as suggested above] would launch a Julia compilation process with corresponding arguments via a separate Julia compiler executable. Thoughts?

[OliverEvans96]

I'm curious whether this is still being actively considered. Would this be basically be a CLI for PackageCompiler? @lucatrv's comment here makes it appear that julia-compile would not fully overlap with PackageCompiler.