Most OS X installations have a case-sensitive filesystem, so "BUILD" is the same as "build".
Some teams have directories/files named "build" in their projects, which poses a double challenge:
At least as a transitionary-aid for other teams, it would be useful to customize the file-name that Bazel uses to define packages.
Suggestion: add a WORKSPACE
rule to define a different file-name.
:+1: It is very common to have a build
folder at the top level of an iOS or Android project for Xcode to put locally built artifacts and generated files. We make this assumption on our CI as well.
I wonder why Bazel allows you to customize the location of a BUILD
file for an external repo (via the build_file
attr on a git_repository
) but won't let you customize the BUILD
file in the workspace root.
It would be as simple as specifying in the WORKSPACE
something like workspace_build_file = "workspace.BUILD"
.
I don't think that's a good idea. We will ends-up having different build file everywhere. We should instead do file type detection and not try to parse a directory as a build file :)
@damienmg the problem we ran into was the opposite - existing scripts (as well as Gradle, in its default configuration) were stepping on the BUILD files we wrote.
If the concern is that we will have different build files everywhere, maybe we could solve this problem by detecting build files by looking for files either called BUILD
(as we do today) or Buildfile
(similar to Makefile
, Gemfile
, etc). That seems unique enough that it won't be trampled by scripts, and also a familiar pattern for developers.
Alternatively, Bazelfile
?
SGTM BUILD.bazel ? (someone was proposing an extension to make it work outside).
Please don't reuse extensions that are already in use for different file types (i.e. please don't use .bzl). BUILD.bld?
If we are adding an extension, I vote in favor of BUILD.bazel
. Another benefit of this is that it is straightforward for people to say:
build dot Bazel
Similarly, Gradle's build files are build.gradle
.
I also need this while trying to migrate from pants
, as it also uses BUILD files for the same purpose as bazel
but with a different syntax...
@katre @jhfield: Too many people reassigning this bug at the same time? :)
I'm looking into it, I promise! :)
Just as an update, work is in progress, I have a mostly working solution but there are a lot of tests to fix up as a result.
As a transitory aid, until this is done, I made a really simple script to patch Bazel. We managed to transition successfully from pants with a ~2 week overlap and then went back to the vanilla Bazel binary after.
find . -type f | grep -E '\.(md|patch|vm|html|bzl|java|c|cc|h|proto|txt|sh|bash|git_log)$' | xargs sed -r -i"" -e 's/\bBUILD\b/UCBUILD/g'
find . -type f | grep -E '(_bazel|Makefile|WORKSPACE|UCBUILD)' | xargs sed -r -i"" -e 's/\bBUILD\b/UCBUILD/g'
find . -type f | grep 'UCBUILD' | xargs rename 's/\bBUILD\b/UCBUILD/'
Has there been any decision as to what the extension/name of this BUILD file not named BUILD is going to be?
The alternate name will be BUILD.bazel. I have the code for this change
mostly working and plan to pick it back up shortly.
On Mon, Oct 10, 2016, 1:54 PM Robert Bradshaw [email protected]
wrote:
Has there been any decision as to what the extension/name of this BUILD
file not named BUILD is going to be?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/552#issuecomment-252693226,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAT7f4ocvnBZ1qCxagMdW9IJNCJO6IfFks5qynu9gaJpZM4GalKt
.
@katre any ETA? this is a pretty frustrating issue for us.
@ixdy Sorry for the slow reply.
I have a change ready and in testing. There's some cleanup I need to do before I can start working to get it out, but it should be in review next week.
Chiming in from Airbnb eng -- we're looking to migrate off of Gradle as well as some of the other folks in this thread and we've run into this issue as well. Would love to see this fix released as soon as it's ready.
I have just this evening submitted the fix for this issue. It should be pushed to GitHub in the next day or so and then be in the December release (presumably 0.4.2, but we will see what the version is).
Most helpful comment
I have just this evening submitted the fix for this issue. It should be pushed to GitHub in the next day or so and then be in the December release (presumably 0.4.2, but we will see what the version is).