remove `compile`?

[MasonProtter]

compile(f, args...) currently compiles code that is intended to be used again from within a future julia session. Given that v1.9 now exists with pkgimages, I'm not sure there's any real point to the whole compile thing.

Should we deprecate it and just focus on the small binaries? compile was a cool experiment and I learned a lot making it, but it's a lot of bloat to keep around.

[brenhinkeller]

Oh good question.. 1.9 does eliminate a lot of the pain points about, say, LV-heavy functions being slow to compile. I'd say your call!

[MasonProtter]

@tshort any thoughts?

[tshort]

I'm okay with deprecating that.

[MasonProtter]

Great. I'll draft up a PR soon. I had a lot of fun, and made some grand plans for that functionality, but the complexity was a bit beyond me, and it's just become a gigantic maintenance burden now.

[PallHaraldsson]

Given that v1.9 now exists with pkgimages, I'm not sure there's any real point to the whole compile thing.

Is compile just for Julia? I mean if I recall you can compile a library and use from e.g. Python etc. Without the Julia runtime. If that's ok, then you can use juliacall from PythonCall.jl project, as done with diffeq. You can call R with RCall.jl, and from with some project. R people use C++, and it would be very nice if they could use Julia instead of it. I mean I think they can, just as Python can, but might not; worry about the full Julia runtime.

Just deprecate it, since a "gigantic maintenance". It's not like it doesn't work from older versions. You may want to at least doc that, and point to how to install them. Then if needed this could be resurrected.

[MasonProtter]

See https://github.com/tshort/StaticCompiler.jl#linked-compilation

[brenhinkeller]

For anyone reading this who's confused, compile could speed up ttfx of Julia functions within a Julia session by statically compiling them, and does a lot of pointer-patching to allow that to all work (so fewer restrictions than the standalone compile_executable and compile_shlib), but now Julia more or less does that by default with native code caching.

If you want to compile and link your Julia code to a standalone executable or shlib that can be used from other languages, then you still want compile_executable or compile_shlib, respectively

[ChrisRackauckas]

I'm not so sure about this. This was one of the major features we were hoping to use from StaticCompiler.jl. A few major use cases are as follows. For one, we have many instances where we have generated code, from systems like ModelingToolkit. There, precompilation applies to the package itself, ModelingToolkit, or the user's package, which is ModelingToolkit code to generate a model. However, it does not apply to creating binaries of the model itself. But there are many instances where a user builds a large model and it would be interesting to have infrastructure so that could be compiled into a binary, i.e. the user at runtime runs their MTK generator to compile a model so that it's just a binary to reuse in future sessions.

Precompilation does not handle this kind of use case, unless instead of generating code directly to compile we give that code to the user as a piece of Julia code to copy-paste into a file, make a fake package, add a PrecompileTools section, and then compile that fake PrecompileTools section. That is a very roundabout way to force the fact that precompilation makes binaries into something that stores proper binaries.

We can for this case just use compile_executable and link to it inside of an ODEProblem construction, but I wanted to make sure it was brought up that "what do we do about storing compilation of code that we are generating" is still a clear issue in this space and compile was probably the most useful tool we had in the ecosystem to handle that problem.

[MasonProtter]

I actually wasn't aware that anyone was interested in using that functionality. I think the problem though is that the functionality from compile, even if it's potentially useful, was very hackily put together, rather verbose, and mostly just a crude attempt at re-implementing the functionality provided by pkgimages.

So I think perhaps there's space to provide something like that, but re-using significantly more of the underlying machinery from pkgimages, instead of the route we took here previously.

[brenhinkeller]

Oh interesting! If you folks are interested I suppose that could change things. If someone wanted to PR a refactored / new version of compile I’d imagine that could be on the table - esp. if that could also make some of the pointer tricks more robust, or at least ensure we’ve had another set of eyes on them

[MasonProtter]

Yeah, the main motivation I had was that it was a rather large chunk of code that I wasn't aware anybody was interested in at all, so an easy target for reducing maintenance burden.