rename JULIA_HOME?

[StefanKarpinski]

JULIA_HOME is a bit confusingly named since it's home from the perspective of the julia program, not the home of julia-related files from the user's perspective. We should always talk about user-facing matters from the user's perspective, so I propose that we rename JULIA_HOME to JULIA_BIN_DIR. Ultimately, it would be nice for JULIA_HOME to be the user's Julia directory, (i.e. currently JULIA_PKGDIR but including rc files and such) but we may need a different name for backwards compatibility, like JULIA_USER_HOME.

[nalimilan]

+1. We could also use JULIA_PREFIX=$JULIA_HOME/.. instead, since IIRC JULIA_HOME isn't really used directly, but rather combined with relative paths which start with ../.

[stevengj]

Probably JULIA_BINDIR for consistency with PKGDIR, and because bindir is a traditional elision in Unixland.

[StefanKarpinski]

JULIA_PREFIX seems appealing if this is somewhat standard, @nalimilan, do you know if it is? Or maybe JULIA_BINDIR since it's fairly obscure so unlikely for someone to use accidentally.

[StefanKarpinski]

Accepted on the milestone, but the first task is to figure out what the name should be. Research on prior art in other languages is necessary.

[stevengj]

In Python it's called BINDIR on my system, essentially because get_config_var gets the Unix build variables:

>>> import distutils.sysconfig as sc
>>> sc.get_config_var('BINDIR')
'/usr/local/bin'

They also have sys.executable to get the executable path:

>>> import sys
>>> print sys.executable
/usr/bin/python

[stevengj]

There doesn't seem to be a good way to get this info in Ruby.

[StefanKarpinski]

Here's my argument for the prefix being the most basic thing we allow overriding:

1. This is how configure / autoconf / etc. work and this kind of thing is their bread and butter, so they're a good example to follow.

2. One generally wants to know the locations of a whole class of things, which can be derived from the prefix path with reasonable defaults: binaries live at joinpath(prefix, "usr", "bin"), shared libraries live at joinpath(prefix, "usr", "lib"), the standard library lives at joinpath(prefix, "stdlib"). We can additionally allow overriding individual locations, if necessary, but the prefix path should be the way to tell Julia the directory under which the standard stuff lives in a standard layout.

Putting these points together, I think we should use the GNU directory variables as a guide and have this arrangement for environment variables and corresponding Julia variables with defaults:

environment variable	Julia variable	default
JULIA_PREFIX	Sys.PREFIX	automatically set by julia
JULIA_BINDIR	Sys.BINDIR	joinpath(Sys.PREFIX, "usr", "bin")
JULIA_LIBDIR	Sys.LIBDIR	joinpath(Sys.PREFIX, "usr", "lib")
JULIA_SRCDIR	Sys.SRCDIR	joinpath(Sys.PREFIX, "src")
JULIA_BASEDIR	Sys.BASEDIR	joinpath(Sys.PREFIX, "base")
JULIA_STDLIB	Sys.STDLIB	joinpath(Sys.PREFIX, "stdlib")

[yuyichao]

I think we should use the GNU directory variables as a guide

In that case the usr should be part of the prefix.

joinpath(Sys.PREFIX, "base")
joinpath(Sys.PREFIX, "stdlib")

These won't work. According to your current scheme it's /base and /stdlib on a system-wise install.

[JeffBezanson]

Right, PREFIX would be nice but I'm not sure it's possible to promise that a certain thing will be located at joinpath(Sys.PREFIX, "foo") on all platforms. The current locations of these things when installed are:

/usr/bin
/usr/lib
/usr/lib/julia  # system images
/usr/share/julia/base
/usr/share/julia/site/stdlib

src is not installed.

[yuyichao]

Other that the default value, the variable name is pretty standard for build system so it looks good to me. I don't think we necessarily have to bound to one default value on all systems either, they can all be set to a specific value relative to prefix at build time, on platform without a working package manager/for standalone binary build, they can certainly be changed (from what we currently use) to give a flatter directory structure if people like that..................