I am having a really tuff time trying to figure out how to generate a redistributable executable with julia. Can you point me in the right direction on a the main webpage to where this is explained in detail?
2 Likes
Zero order answer: You can’t.
First order answer: Apps · PackageCompiler.
10th order answer: GitHub - tshort/StaticCompiler.jl: Compiles Julia code to a standalone library (experimental)
3 Likes
-1st order answer: Why do you want to?
1 Like
So its a programming language to heal the planet together, but you can’t make a redistributable binary for non-tech people to be able to take advantage of it??
Seems counter to Edelman’s TEDxMIT talk.
Besides that I would think that a programmer would want to lock down his code into an executable binary file before handing it over to a user for production use.
Sincerely,
Jon
5 Likes
I have tried PackageCompiler. I don’t understand what it produced. It looked like it produced a bunch of object files for the julia base system dependencies and a copy of the julia program itself, but no exe other than that.
Did I miss something?
Sincerely,
Jon
Dear Jon:
I don’t know about healing the planet. But creating a standalone app in julia would certainly be desirable. It is not possible yet in a practical way. The first order answer in @carstenbauer’s post allows you to do that. The disadvantage is that you must bundle the whole julia runtime with it, which produces a very large executable even for the smallest examples.
The efforts to get StaticCompiler seem promising but there is still some way to cover before that is practical to do and works in all situations.
1 Like
It is possible to do this: How to give someone your code to run
1 Like
I guess part of this is much of the Julia community are idealists, “locking down the code” doesn’t sound like an advantage to me.
3 Likes
Hi @Jon_Marcum, it is possible to create an executable with PackageCompiler, try to follow the documentation on Apps · PackageCompiler, especially the part of creating an app using the creat_app function. Once you ran everything the executable should be inside the compiled_app folder that you passed to the function. For the executable to work you must share the entire folder that comes with the dependencies.
4 Likes
I’ll try that again. It didn’t seem to work right the couple of times I did it.
Thanks
I would think you wouldn’t want an end user monkeying around with your code and detrimentally changing the program for the intended purpose. This would be especially true for mission critical software like structural engineering software or satellite or plane telemetry tracking software. You are wanting the software to work as expected and not have just anyone to have access to a script file to change it beyond its intended purpose for ill or for good.
1 Like
You can make a redistributable binary, but that is actually counter to healing the planet “together”.
New in Julia 1.8, you can “lock” your code:
- New option
--strip-metadata[…]- New option
--strip-irto remove the compiler’s IR (intermediate representation) of source code when building a system image. The resulting image will only work if--compile=allis used, or if all needed code is precompiled (#42925).
All fully compiled binaries, e.g. for Windows, do not work on other platforms, why I mention not helping to work together (that’s also the default with in other languages). There’s nothing opposed to compiling for many platforms, or just distributing source code, even better for science.
PackageCompiler.jl should work with all code, yes it makes a folder not one file but that’s untrue:
At least in most cases you can strip out the largest dependency LLVM (and slim the sysimage).
I suppose there are external tools that can take a/the folder, for and make a serf-extracting Windows .exe installer, one file. That’s very often done for other languages, i.e. one file in the end isn’t the norm.
You CAN compile some Julia code down to one binary file e.g. 9 KB, but that’s with a different tool, and still the exception.
I would have thought that changing things for good should be encouraged?
The solution that I proposed can constrain the user to run precisely what is intended, however.
1 Like
Sure you do. It’s called open source software, and is gaining considerable traction: Open-source software - Wikipedia
4 Likes
If you want the local lumber yard to design a beam that the building department will accept, it needs to be done by a trained technician using software approved by the building department. Not something that would allow open source software. (Edit, this is the only use case in our jurisdiction that will allow a non-engineer or non-architect to design something that is not in the prescriptive part of the building code.)
I appreciate open source software and being able to fiddle with it. I also take responsibility for that. There are use cases where that is a liability that will not be tolerated.
The ideal is to cater to both use cases.
1 Like
There are still some other options for redistributing your package. How about writing some shell scripts that downloads and installs the package automatically? Of couse, this operation would require an existing Julia instance has already been installed but it is also current for some other language such as Java.
This is kind of important for industry use-cases outside of academia.
10 Likes
2 Likes
Unless there are trade secrets involved, I can think of no reason it couldn’t be open source, and plenty of reasons it should.
You presumably mean they should be running an approved version of the software, but that has nothing to do with whether it’s open source. Open source just means there can be more oversight and transparency.
9 Likes
click_me_and_do_not_think_anything_else.bat is a neat idea! I liked it and starred. Also followed! Thank you.
1 Like