Why to avoid baking absolute paths into our precompiled files?

[fingolfin]

The README says: "we typically do not want to bake absolute paths into our precompiled files" but gives no clue as to why.

Could you elaborate? For my particular application, it would tremendously simplify things if I could access the scratch space during precompilation. Background: my scratch space contains symlinks into JLL artifacts. Whenever those JLLs get updated, I need to regenerate the symlinks. By far the easiest way to do this is to simply regenerate the scratch space during precompilation of my package, which AFAIK is guaranteed to happen whenever one of its JLL dependencies changes.

So far this seems to work well, but this off hand remark in the Scratch.jl README.md makes me worry there are issues I am not aware of.

[fingolfin]

@staticfloat Apologies for bugging you, but since according to git that line of text was written by you, I am hoping you can clear this up?

[fredrikekre]

I assume for ~portability~ relocatability.

[fingolfin]

Relocatability of the output of precompilation? I wasn't even aware that's a thing :-). Could you give me a pointer when / how that might happen?

[fredrikekre]

See e.g. https://julialang.github.io/PackageCompiler.jl/dev/devdocs/relocatable_part_3/#Why-is-the-built-executable-in-the-previous-tutorial-non-relocatable?-1

Relocatability is not an absolute measure [...] other (implicit) assumptions, like embedding absolute paths into source code would make the app almost completely non-relocatable since that absolute path is unlikely to exist on another machine.

However, you can construct an example without PackageCompiler too.

[staticfloat]

Yep. Another example is if you have a depot that gets mounted at different places, e.g. if you mount your depot into a docker container.