Skip to content
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

multi_sass_binary permission denied exclusive packages same directory #97

Open
eachirei opened this issue Sep 20, 2019 · 4 comments
Open

Comments

@eachirei
Copy link

eachirei commented Sep 20, 2019

Reproduction:
Folder sass_test, containing empty files A.scss and B.scss.

load("@io_bazel_rules_sass//:defs.bzl", "multi_sass_binary")

SHARED_COMPONENTS = [
    "B.*"
]

print(glob(["*.scss"], exclude = SHARED_COMPONENTS))

multi_sass_binary(
  name = "A",
  srcs = glob(["*.scss"], exclude = SHARED_COMPONENTS)
)

print(glob(SHARED_COMPONENTS, exclude = ["*.html", "*.ts"]))

multi_sass_binary(
  name = "B",
  srcs = glob(SHARED_COMPONENTS, exclude = ["*.html", "*.ts"])
)

Output

bazel build //src/sass_test:A --verbose_failures
DEBUG: ../src/sass_test/BUILD.bazel:7:1: ["A.scss"]
DEBUG: ../src/sass_test/BUILD.bazel:14:1: ["B.scss"]
INFO: Analyzed target //src/sass_test:A (128 packages loaded, 1706 targets configured).
INFO: Found 1 target...
Target //src/sass_test:A up-to-date:
  dist/bin/src/sass_test/A.css
  dist/bin/src/sass_test/A.css.map
INFO: Elapsed time: 1.777s, Critical Path: 0.40s
INFO: 1 process: 1 local.
INFO: Build completed successfully, 7 total actions

bazel build //src/sass_test:B --verbose_failures
DEBUG: ../src/sass_test/BUILD.bazel:7:1: ["A.scss"]
DEBUG: ../src/sass_test/BUILD.bazel:14:1: ["B.scss"]
INFO: Analyzed target //src/sass_test:B (0 packages loaded, 2 targets configured).
INFO: Found 1 target...
ERROR: ../src/sass_test/BUILD.bazel:16:1: Compiling Sass failed (Exit 66): sass failed: error executing command 
  (cd /private/var/tmp/_bazel_username/uuid/execroot/project && \
  exec env - \
  bazel-out/host/bin/external/io_bazel_rules_sass/sass/sass --style compressed --load-path src/sass_test src/sass_test:bazel-out/darwin-fastbuild/bin/src/sass_test)
Execution platform: @bazel_tools//platforms:host_platform
Error reading bazel-out/darwin-fastbuild/bin/src/sass_test/A.css.map: permission denied.
Target //src/sass_test:B failed to build
INFO: Elapsed time: 0.361s, Critical Path: 0.24s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

Am I doing something wrong?
The use-case would be the following: Angular project, has 2 modules inside same folder for convenience; module A is standalone, but module B is used by another module, yet both share the same scope so to say.

@nex3
Copy link
Collaborator

nex3 commented Sep 23, 2019

It looks like multi_sass_binary isn't actually using the srcs to generate the Sass command line; it's implicitly assuming that all Sass files will be compiled. @kyliau, would you be able to look into fixing that? We should probably generate a separate input:output pair ourselves for each source file.

As an aside, it's a good idea to avoid multi_sass_binary when doing anything complex. It's provided as a way of getting projects up and running quickly, but it doesn't provide any tracking of the actual dependency tree of Sass files so it'll end up doing a lot of extra work on each recompilation that would be avoided with fine-grained use of sass_library and sass_binary.

@eachirei
Copy link
Author

How should I write a bazel file for an angular module with multiple components without multi_sass_binary and without modifying it each time we add or remove a new component? Cause that can become quite a hassle, especially for new developers coming to the project. I'm not asking this in a mean way, I'm just trying to understand better the whole bazel environment.

@nex3
Copy link
Collaborator

nex3 commented Sep 25, 2019

In general, you should expect to update your BUILD files whenever you change the dependency structure of your app. That's an inherent constraint of incremental rebuilds in a builds system like Bazel where the configuration is defined strictly independently of the contents of the input files.

You can mitigate this overhead with an automated BUILD file generator; #75 is a work in progress in that direction.

@Serginho
Copy link

👍 Same problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants