You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assembly rules often depend on other assembly rules - for example a targz assembly may depend on building JARs to package internally. Most assembly rules take a global constant called version and use it to append the version number to the distribution file names.
However, this can lead to the following situation:
where the dependency-main comes from a different repository that is on a different version number, let's say 1.0.0. In this case, we actually write an incorrect version number.
The general problem is that the version number is set globally in the root workspace and used for all build targets triggered.
Current Workaround
The best we can do is not to use a verison number at all.
Proposed Solution
Require extension to bazel:
Allow hierarchical workspaces to be loaded, each with their own constants & definitions
or
Allow defining a version number contextualised to each target (eg. rule instance), rather than each rule.
The latter would require a very verbose set of definitions at the root target, such as @dependency//:main.version=1.0.0, doing this for each target in the build tree requiring a version number.
The text was updated successfully, but these errors were encountered:
Problem to Solve
Assembly rules often depend on other assembly rules - for example a
targz
assembly may depend on building JARs to package internally. Most assembly rules take a global constant calledversion
and use it to append the version number to the distribution file names.However, this can lead to the following situation:
where the
dependency-main
comes from a different repository that is on a different version number, let's say 1.0.0. In this case, we actually write an incorrect version number.The general problem is that the version number is set globally in the root workspace and used for all build targets triggered.
Current Workaround
The best we can do is not to use a verison number at all.
Proposed Solution
Require extension to bazel:
or
The latter would require a very verbose set of definitions at the root target, such as
@dependency//:main.version=1.0.0
, doing this for each target in the build tree requiring a version number.The text was updated successfully, but these errors were encountered: