-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds toolchain for freebsd. #794
Adds toolchain for freebsd. #794
Conversation
Sorry for the massive delay here! I'd love to support Freebsd but unless we have something that runs in CI, there's a big risk of regression and I don't think we can confidently say we actually "support" it without tests. I think it'd be good to try and ping bazelbuild/continuous-integration#258 to communicate to Google that there's interest in Freebsd test runners. |
@UebelAndre indeed. I've pinged on that thread, but it would still be neat to have each piece that Bazel depends on be ready regardless anyway. FreeBSD packages Bazel and currently because of all the breakages the experience is somewhat lacking. I think we can build the car and the road will come. wdyt? I've also sent a PR for While we wait for a CI, people like me who use FreeBSD can help report any issues. Over time when you have CI support, |
My opinion would be to merge this despite not having any testing capacity but with the caveat that changes will only be propagated to this platform on a best effort. We'd rely on you as freeBSD users to keep this updated? I know in the past cockroachdb have been using a fork that supports freeBSD so having support in the main repo would mean that they could move to the main releases of rules_foreign_cc? |
@UebelAndre do you have any opinions on this? |
I'm worried about our inability to test those code paths for future changes. If someone makes a change, then unless we have failing tests for BSD then I would say there's no obligation for them to care about that environment. Which would very likely frustrate BSD users who had their builds break after that commit. If there's a good story for managing expectations or these code paths then I'm for it |
I'd say we shouldn't worry about frustrating FreeBSD users (having a build that works is better than one that doesn't, no?). I can send patches for changes in the meantime because I'm using Bazel on FreeBSD. best effort is alright with me. :) |
@UebelAndre Sure thing! |
…into add-toolchain-for-freebsd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Hi @UebelAndre please wait before merging this PR. Cross-checking a few things. My PR to bazel-skylib got merged but bazel-skylib in this repository is tracking release version 1.1.1. There haven't been releases since September 27 but the tests require a new release to pass for FreeBSD. Would you be okay with including a non-release version of bazel-skylib here (not sure what the policy for Bazel projects says)? |
Test results attached:
Additional patch required (I'll change 'main' to the commit ref if this is okay):
|
I think that's fine to use a commit vs a release for |
Hey @UebelAndre done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me if it looks good to @jsharpe!
I've got this passing all tests (with caveats) and building libraries (e.g. libdill). However,
I'm running into a rather tricky issue. The shebang line for a couple tests starts as follows:
while it should ideally be
#!/usr/bin/env bash
(preferable)or
#!/usr/local/bin/bash
(where thesudo pkg install bash
installs it on FreeBSD).
OS and compiler:
Tests
The tests pass if I create a symbolic link for bash here
/bin/bash
.How do I get the test shell scripts to use the correct shebang line
without having to resort to creating a symbolic link as a workaround?
With workaround symbolic link:
The tests that fail without the workaround are:
The Error: