Open hzeller opened 3 years ago
This is slightly difficult for me to tackle - I don't have any non-linux machines where I could develop this. I think the best way for me to fix it would be to write a python-based installed to fix #23
In my case, I could solve for verible install on MacOs, modifying the generated file:
bazel-bin/_install_gen.sh
by removing manually -T
, and running afterward:
bazel-bin/install -- /usr/local/bin
Is the -T
option actually needed ? At that point in the script it should be sufficiently certain that the source and destination are non-directory items (maybe there could be a test in the shellscript itself).
Would be good if we don't have to rely on the -T
option that only seems to be available in gnu-install.
Version: bazel_rules_install tag 0.4. Not sure what MacOS exactly, uname spits out something like
Darwin Kernel Version 19.6.0
When compiling a project that compiles with bazel on MacOS (in my case: verible), the install procedure is not working, possibly because the install on MacOS is a BSD install, not GNU install.
In particular it seems to stumble upon the
--
separator between options and arguments.Looking at the
bazel-bin/_install_gen.sh
(which I suspect is the one invoked) contains the following snippet, which is possibly the culprit:I know that MacOS is still on the TODO list, but I hope this actual use-case might help raise the awareness (we just recently were able to get the project to compile on MacOS, so this would be the final stumbling block).
Maybe as a first step, the
--
could only be emitted if the target looks like it would be in danger to be interpreted as option ? Given that binaries rarely (if ever) start with dash, this should fix the typical use-case.