@fullofcaffeine asked how I managed various versions of Haxe, so here’s just a quick core dump.
For all these commands, rather than sprinkling sudo everywhere, I’m going to assume your user owns the
/opt directory. You can affect that ownership with:
sudo chown $USERNAME:$USERNAME /opt
I untar various versions of Haxe in
/opt/ – any of the following will do:
cd /opt/ curl -sL https://github.com/HaxeFoundation/haxe/releases/download/4.0.0-rc.1/haxe-4.0.0-rc.1-linux64.tar.gz | tar -xz curl -sL https://github.com/HaxeFoundation/haxe/releases/download/3.4.7/haxe-3.4.7-linux64.tar.gz | tar -xz
Ok, so this untarred some long directory names – I want them to be short and descriptive:
mv haxe_20180221160843_bb7b827 haxe-3.4.7 mv haxe_20190201170222_1fdd3d5 haxe-4.0.0-rc.1
Great, now I have
Now I’ll create a symlink of
/opt/haxe to whichever version of Haxe I want to be the globally installed one. And I’ll symlink the haxe and haxelib binaries to
/usr/bin to make them available to all users (typically just me):
cd /opt ln -s haxe-4.0.0-rc.1 haxe cd /usr/bin sudo ln -s /opt/haxe/haxe . sudo ln -s /opt/haxe/haxelib .
Ok, and we’ll do the same setup for neko (though it appears you might not need neko if you’re only working with Haxe 4+):
cd /opt curl -sL http://nekovm.org/media/neko-2.1.0-linux64.tar.gz | tar -xz cd /usr/bin sudo ln -s /opt/neko-2.1.0-linux64/neko .
Now, Haxe can sometimes auto-detect the following, but I find it’s safest to just specify it. I often put these in my
~/.bashrc, though they could/should go in
/etc/profile.d/haxe.sh to truly be part of the “system-wide install”:
export HAXE_STD_PATH=/opt/haxe/std export NEKOPATH=/opt/neko-2.2.0-linux64
Ok, if all went well, I have haxe and neko installed:
> haxe -version 4.0.0-rc.1+1fdd3d5 > neko -version 2.1.0
And changing the system-wide version of Haxe is as easy as changing the symlink:
cd /opt rm haxe ln -s haxe-3.4.7 haxe
(Or, if you’d rather remember these args, you don’t need to rm haxe first:)
ln -sfn haxe-3.4.7 haxe
And check it:
> haxe -version 3.4.7
Great. So that’s the system-wide install.
But note that I can, for one (shell) session or one script, override the system install by placing the other version on the front of my
PATH (which then overrides the binaries in
/usr/bin), and overriding
For a shell session, I can simply type:
export PATH=/opt/haxe-4.0.0-rc.1:$PATH export HAXE_STD_PATH=/opt/haxe-4.0.0-rc.1/std
Now for the rest of that shell, I’m using the specific Haxe version.
If I wanted to use these variables for one single command only, you can prefix those env variables to the command:
PATH=/opt/haxe-4.0.0-rc.1:$PATH HAXE_STD_PATH=/opt/haxe-4.0.0-rc.1/std haxe my_build.hxml
But that’s quite a mouthful. Let’s make an alias for that (you can save this in
~/.bashrc or in
alias haxe4='PATH=/opt/haxe-4.0.0-rc.1:$PATH HAXE_STD_PATH=/opt/haxe-4.0.0-rc.1/std haxe'
Excellent. Now the
haxe4 alias invokes haxe 4, even if haxe 3.4.7 is my system-wide haxe. So I can type:
> haxe -version 3.4.7 > haxe4 -version 4.0.0-rc.1+1fdd3d5
Some will argue that a system-wide installation of Haxe is bad / singleton-esque. Meh – I want “the typical” version installed and always ready. If a project needs a specific version of Haxe, I’ll either switch my shell (shown above), or setup some docker CI scripts and a .travis.yml for that project (using all the commands you just learned above!)
If you learn about environment variables, symlinks, and docker, you’ll have an extremely powerful set of tools in your belt!