-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Standardize the entry-point for Julia execution
This is a bit of a straw-man proposal (though I think mergable if people agree) to standardize the execution entrypoint for Julia scripts. I think there's at least four different ways that people might run a script: - As `julia main.jl` - As a PkgCompiler sysimage, then calling the main entry point - As a PkgCompiler "app", with the magic `julia_main` function - As a StaticCompiler product with an explicit entrypoint specified on the API. The main problem I have with all of these variants is that they're all different and it's kind of a pain to move between them. Here I propose that we standardize on `Main.main(ARGS)` as the entrypoint for all scripts. Downstream from that proposal, this PR then makes the following changes: 1. If a system image has an existing `Main.main`, that is the entry point for `julia -Jsysimage.so`. 2. If not, and the sysimage has a REPL, we call REPL.main (we could handle this by defaulting `Main.main` to a weak import of `REPL.main`, but for the purpose of this PR, it's an explicit fallback. That said, I do want to emhpasize the direction of moving the REPL to be "just another app". 3. If the REPL code is called and passed a script file, the REPL executes any newly defined Main.main after loading the script file. As a result, `julia` behaves the same as if we had generated a new system image after loading `main.jl` and then running julia with that system image. The further downstream implication of this is that I'd like to get rid of the distinction between PkgCompiler apps and system images. An app is simply a system image with a `Main.main` function defined (note that currently PkgCompiler uses `julia_main` instead).
- Loading branch information
Showing
6 changed files
with
103 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters