[request] Make it easier to produce nimrtl/nimhcr, reccomend in docs setting rpath to $ORIGIN for using nimrtl/nimhcr

[awr1]

In the docs it is shown that you can generate nimrtl using the following command nim c -d:release lib/nimrtl.nim, but this does not work in any arbitrary directory - you have to have the standard library folder on hand (or a copy of nimrtl.nim in your project that you build separately, which, to be fair, is very short as it includes the whole standard library directly).

So, some suggestions:

• Make it easier to be able to just build nimrtl/nimhcr from anywhere, i.e. possibly add a new compiler switch?
• Add nimhcr build instructions to the docs
• Docs might do well to suggest setting rpath to $ORIGIN on *nix systems if nimrtl/nimhcr are not installed as system libraries (which I assume people probably aren't doing) and are to be bundled with the binary in the same folder. (This doesn't need to be done for Windows, b/c on Windows DLL loading searches the app dir by default)

[alaviss]

We can also just enforce the building of nimrtl/nimhcr as part of the distribution. On *nix packages can install nimrtl/nimhcr to /usr/lib, allowing it to be shared with all nim projects.

[awr1]

@alaviss

• If we install to system lib directories on *nix, where does that leave Windows?
• Doesn't that mean we would require sudo privileges for installing Nim? If we did end up doing this, wouldn't it be best to just symlink from /usr/lib to a local Nim install? Would make choosenim's job easier

[alaviss]

If we install to system lib directories on *nix, where does that leave Windows?

We'll need a way to easily generate them for windows, but that's already possible, maybe just some magic to have them generated when hcr is enabled:

nim c --outdir:%CD% \path\to\nimhcr.nim
nim c --outdir:%CD% \path\to\nimrtl.nim

In that case then rpath $ORIGIN could also be used on Linux.

Doesn't that mean we would require sudo privileges for installing Nim?

Well, I was focusing on packages provided by distributions, not via choosenim, sorry for not making that clearer.

For universal behavior then maybe rpath magic can be used on Linux. That'd work no matter how an user install nim on their machine.

[awr1]

ultimtately I was thinking of either something like:

• --inStd, which changes the input parent directory to the Nim stdlib path, which could then be followed be lib/nimrtl.nim or lib/nimhcr.nim. Ideally we should like to keep the output relative to whatever current directory we are in the shell.
• nim c --genRtl and nim c --genHcr, with no input source argument needed.

[Araq]

Add nimhcr build instructions to the docs

Yes.

Docs might do well to suggest setting rpath to $ORIGIN on *nix systems if nimrtl/nimhcr are not installed as system libraries (which I assume people probably aren't doing) and are to be bundled with the binary in the same folder. (This doesn't need to be done for Windows, b/c on Windows DLL loading searches the app dir by default)

Yes, please.

[oakes]

Is the plan to eventually include nimrtl and nimhcr in the distribution or will they always need to be compiled separately?

[Araq]

They are part of the distribution, but how to set them up remains unclear. Will investigate.

[oakes]

Thanks @Araq , i saw that they were in the distribution in source form but couldn't find them in binary form. I tried building them myself but no luck so far.