-
-
Notifications
You must be signed in to change notification settings - Fork 661
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
new_go_repository does not work with golang.org/x/text on macOS #144
Comments
Thank you for reporting the issue.
No. Technically it is possible to automatically generate a Actually I have a plan to add such a mode to Gazelle for packages vendored with "git submodule". c.f. #16 (comment). @swsnider |
I can try, but I was having issues getting my overlay build file to look right to the new rules. I'll see if I can infer the Chevy structure from the partial ones being generated. |
There is an upcoming change to bazel where BUILD files are allowed to be On Thu, Oct 13, 2016 at 9:43 AM, Silas Snider notifications@github.com
|
Has there been any movement on this issue? I've tried creating a
This fails to build with errors like |
the change we need from bazel is under review, so it should only be another week or two until we can make the changes to gazelle. I think you have to create a target for each directory And so forth for every library in there. |
It looks like 0.4.1 allows 'BUILD.bazel' - is this still blocked? |
Nice - I hadn't seen that 0.4.1 was out. Should be unblocked for someone
to do the work.
…On Thu, Dec 1, 2016 at 12:19 PM, Ryan Michael ***@***.***> wrote:
It looks like 0.4.1 allows 'BUILD.bazel' - is this still blocked?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#144 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALF-0gQ0LAvOclv_msO9TqrCMhd2IEMUks5rDwGSgaJpZM4KVi4t>
.
|
This should be fixed by #228. |
This seems to be working now. I'm able to run |
This isn't working for me on bazel 0.4.5 and rules_go at 7cce22e.
|
I had to add an explicit This seems like something rules_go could be defaulting to for versions at 0.4.5 and later? |
I'll double-check on this. It does seem like something we should be defaulting to. |
Generated BUILD files may conflict with other files or directories named "build" on case insensitive file systems. "BUILD.bazel" is less likely to conflict, and Bazel supports these files since 0.4.1. The filename can still be overridden by specifying the build_file_name attribute. This just changes the default. Fixes bazel-contrib#144
Generated BUILD files may conflict with other files or directories named "build" on case insensitive file systems. "BUILD.bazel" is less likely to conflict, and Bazel supports these files since 0.4.1. The filename can still be overridden by specifying the build_file_name attribute. This just changes the default. Fixes #144
* run go generate for new stdlib
Since golang.org/x/text/collate/build is a package, and macOS by default has a case-insensitive (but case-respecting) filesystem, I cannot use new_go_repository with that package.
Before new_go_repository existed, I was overlaying my own BUILD files using new_git_repository, which did not have this issue because I used on per repository, instead of one per package.
Apparently it is in some cases possible to convert your filesystem losslessly to case-sensitive using iPartition, but that doesn't work if you're encrypting your hard drive.
Can the new_go_repository rules be changed to use this same approach? Or is there a technical reason why that wouldn't work?
This came up because I'm actually trying to depend on an entirely different package, afero, using the following WORKSPACE
The actual error is:
The text was updated successfully, but these errors were encountered: