Problems with installing OpenFl 7.0.0 on a Mac

After using “haxelib install openfl” a folder name 7.0.0 was installed in the openfl folder which is in the haxelib folder.

After using “haxelib run openfl setup” I get this:

To finish setup, we recommend you either...

 a) Manually add an alias called "openfl" to run "haxelib run openfl"
 b) Run the following commands:

sudo cp "/Users/Athena/haxelib/lime/5,8,2/templates/bin/" /usr/local/bin/lime
sudo chmod 755 /usr/local/bin/lime
sudo cp "/Users/Athena/haxelib/openfl/7,0,0/src/templates/bin/" /usr/local/bin/openfl
sudo chmod 755 /usr/local/bin/openfl

I tried to run those commands but the 3rd sudo cp command causes a “No such file or directory” error. There is no templates folder inside the src folder. The folder structure for the 7,0,0 folder is totally different then the still present 6,3,0 and 6,5,0 folders. They have the folders docs, externs, haxe, openfl, templates, tools whereas the 7.0.0 the folders assets, bin, docs, hooks, lib, scripts, src.

I found a templates folder inside 7,0,0/assets that had the same folders as the templates folder inside the 6,3,0 and 6,5,0 folders. So I tried referencing that folder which got rid of the “No such file or directory” error. However using the openfl command gave me “OpenFL Command-Line Tools (null-LGL85z)”

I use Visual Studio Code which normally under HAXE DEPENDENCIES lists openfl (6.5.0), lime (5.8.2) and std (3.4.4). After my attempts to install 7,0,0 only std (3.4.4) is listed and trying to build an older project that worked under 6,5,0, just gives a bunch of errors.

After replacing the oepnfl folder with the previous one with just 6,3,0 and 6,5,0, everything work just fine. Using the openfl command gave me “OpenFL Command-Line Tools (6.5.0-LGL85z)”


Hi! Sorry for the trouble :slight_smile:

You should be able to do sudo haxelib run openfl setup -cli to install only the command-line alias, using sudo so you have write permissions.

It looks like that third command above should’ve been:

sudo cp "/Users/Athena/haxelib/openfl/7,0,0/assets/templates/bin/" /usr/local/bin/openfl

Sorry for the trouble!

Sorry, that didn’t work. In fact I had already tried that. And using the “-cli” parameter didn’t seem to change anything. After reinstalling, the openfl command still gives me “OpenFL Command-Line Tools (null-LGL85z)” and I still only get std (3.4.4) listed under HAXE DEPENDENCIES in VSC.

Oh, well once haxelib run openfl setup -cli works, you should be able to use openfl instead of haxelib run openfl to access the OpenFL command. From the sound of it, this part of the process already worked.

Perhaps why the command-line tools are prompting null is either that your Lime version is too old, or your Haxe + Haxelib version is too old. Are you using Haxe 3.4.4?

Lime was the wrong version which I discovered in a strange way. I used the openfl command and got “OpenFL Command-Line Tools (6.5.0-LGL85z)”. Then I tried using “openfl setup” just to see what would happen. Got this:

Downloading lime-6,0,
Download complete : 92429156 bytes in 26s (3465.6KB/s)
Installing lime...
  Current version is now 6.0.1
hxcpp is up to date
lime-samples is up to date
openfl-samples is up to date
actuate is up to date
box2d is up to date
layout is up to date

When I opened VSC I got an error message about incompatibility with Lime 6.0.1. Then I redid the haxelib install openfl and haxelib run openfl setup commands. This time I got the list of things that were up to date including Lime, which I did not get in any of my previous uses of haxelib run openfl setup. Nor did I get any of the “To finish setup” stuff, just “Do you want to install the ‘openfl’ command?” which I did. Then with the openfl command I got “OpenFL Command-Line Tools (7.0.0-LTglgq)”. When I restarted VSC, the new versions of Lime and OpenFl were under HAXE DEPENDENCIES and I was able to successfully build my old project with OpenFl 7.0.0.

Why didn’t somewhere during or after the first download and install of 7.0.0, a new version of Lime was installed or at least a note saying it needed to be updated?

Why would redoing the setup under 6.5.0 make the installation of 7.0.0 work?

Thanks for your help!

Strange! Well I’m glad it’s all cleared up. I think this would not be a problem with a new install on a fresh machine, but something must have been funny with previous versions