lfc and build-lfc errors on MacOS after commit 7249b778283cbf0b63623a9f0427684755da7f1b

[housengw]

Here's the error message:

oysteryio-2:bin wonghouseng$ lfc
readlink: illegal option -- f
usage: readlink [-n] [file ...]
/Users/wonghouseng/Desktop/lingua-franca/bin/lfc: line 11: ./init.sh: No such file or directory
/Users/wonghouseng/Desktop/lingua-franca/bin/lfc: line 14: find_jar_path: command not found
/Users/wonghouseng/Desktop/lingua-franca/bin/lfc: line 15: fatal_error: command not found
/Users/wonghouseng/Desktop/lingua-franca/bin/lfc: line 19: check_jre_version: command not found
/Users/wonghouseng/Desktop/lingua-franca/bin/lfc: line 22: run_jar_with_args: command not found

Based on a brief search, seems like the cause is that readlink on Mac does not have the --f flag.

[lhstrh]

Thanks for reporting this! It is unfortunate that lfc stopped working on MacOS. We use readlink --f to ensure that symlinks don't break our scripts. I'm not sure how to do this on Mac. In a quick search, I found this: https://stackoverflow.com/questions/29836821/how-does-this-os-x-bash-script-that-emulates-linuxs-readlink-work

We might want to check $OSTYPE and do platform-specific things here. Before doing this, however, we should set up a CI job that tests lfc on the various platforms so that we can guarantee all of this works...

[lhstrh]

One option would be to greadlink -f from coreutils (and tell the user to brew install coreutils if greadlink cannot be found).

Would this be acceptable, or should we really write our own bash code to resolve this?

One advantage of the greadlink approach is that we can push a fix quickly...and we could push a custom solution without dependencies later...

[Soroosh129]

I think we shouldn't assume probably that brew is installed on MacOS since it is not a natively installed application and it is not a light commitment to install it.

[Soroosh129]

Should we revert the merge until this is resolved?

[lhstrh]

Doing so will break lfc.ps1 so I’d prefer not to. We could push a fix tonight…

On Wed, Oct 20, 2021 at 4:07 PM Soroush Bateni ***@***.***> wrote: Should we revert the merge until this is resolved? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#651 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYD47F7XUY4QPCMTTVGND3UH5DRXANCNFSM5GMWYQCQ> .

--

…

-- Marten Lohstroh | Postdoctoral Researcher University of California | 545Q Cory Hall Berkeley, CA 94720 | +1 510 282 9135

[Soroosh129]

I wouldn't be able to help out tonight. I can take a stab at it tomorrow morning.

[lhstrh]

BTW, I would have expected ./gradlew :org.lflang.lfc:test --stacktrace to have picked up on this problem because we run it for all platforms, not just for Linux. I haven't yet looked into what these test actually do, but the current tests do not suffice.

[cmnrd]

Our tests don't use the lfc script. In fact, the lfc artifact isn't even build in our CI flow. I opened #320 and #575 pointing this out, but never got to fixing it.

Since we now test the benchmark runner script on Linux, we have at least a little coverage regarding the lfc script.

[lhstrh]

In lieu of tests (forthcoming) could you please check whether lfc and build-lfc work on Mac on the lfc-test branch?