Don't use select in srcs #134
Comments
Platform-specfic srcs, separated with select expressions, have caused a few problems. If the goos and goarch attributes of go_binary are used, the wrong set of sources may be compiled. rules like go_path will get filtered lists of sources without any way to get the unfiltered list. Separating sources is largely unnecessary, since rules_go also filters sources at execution time. Therefore, this separation is being removed by Gazelle. * Rules generated by gazelle will now have flat srcs lists. * Existing srcs lists will be flattened by "gazelle update" before merging. Sources that appear multiple times will be de-duplicated, and comments will be consolidated. Note that Gazelle still filters sources, it just doesn't generate select expresions for them anymore. Unbuildable sources (e.g., with +build ignore) will not appear in any list. Dependencies and flags will still be platform-specific. Fixes bazel-contrib#134
Platform-specfic srcs, separated with select expressions, have caused a few problems. If the goos and goarch attributes of go_binary are used, the wrong set of sources may be compiled. rules like go_path will get filtered lists of sources without any way to get the unfiltered list. Separating sources is largely unnecessary, since rules_go also filters sources at execution time. Therefore, this separation is being removed by Gazelle. * Rules generated by gazelle will now have flat srcs lists. * Existing srcs lists will be flattened by "gazelle update" before merging. Sources that appear multiple times will be de-duplicated, and comments will be consolidated. Note that Gazelle still filters sources, it just doesn't generate select expresions for them anymore. Unbuildable sources (e.g., with +build ignore) will not appear in any list. Dependencies and flags will still be platform-specific. Fixes #134
|
This fixed selection of source files however dependencies |
|
@afking Unfortunately, there's no practical way to fix that within rules_go or Gazelle. Attributes like |
|
There is also the issue of CGo files ( |
|
@steeve That should not be happening. Could you file an issue on rules_go with steps to reproduce? Gazelle should include .c files if there is at least one .go file with rules_go should filter those files for the target platform based on tags and filename suffixes before attempting to compile them. |
|
I think |
|
@steeve We pass the full set of If there's a case where a .c file should not be matched but is compiled anyway, please file a bug. |
Currently, Gazelle identifies platform-specific source files using file name suffixes (e.g.,
foo_linux_amd64.go) and build tags (e.g.,// +build linux,amd64).It's important that we don't attempt to build packages that are only imported by platform-specific sources that wouldn't get compiled for the target platform. Building the wrong packages causes errors and wastes resources.
That said, there's actually no need to exclude platform-specific sources at analysis time. The compiler wrapper in rules_go also checks build constraints at execution time, so this early exclusion is redundant (even though it saves us a little time).
In some cases (particularly when
goosandgoarchare set on ago_binaryrule), sources that should be included are excluded byselectexpressions. There's no way to evaluate these expressions correctly in the presence ofgoosandgoarchattributes. We should avoid using them when they're not necessary.The text was updated successfully, but these errors were encountered: