Skip to content

api/build: switch to only package level targets in API.#8495

Merged
htuch merged 6 commits intoenvoyproxy:masterfrom
htuch:build-pkg-xform-gen
Oct 6, 2019
Merged

api/build: switch to only package level targets in API.#8495
htuch merged 6 commits intoenvoyproxy:masterfrom
htuch:build-pkg-xform-gen

Conversation

@htuch
Copy link
Copy Markdown
Member

@htuch htuch commented Oct 4, 2019

As part of #8082, we want to be able to (1) automatically generate BUILD
files and (2) treat packages as atomic from a "upgrade / do not upgrade"
decision perspective. This is simplified by having our BUILD targets at
package granularity, since this is what the protoxform plugin operates
on.

This PR broadens the package-level treatment that was already introduced
for Go in #8003 to Python and C++. This simplifies BUILD files
significantly and opens the way to automated generation.

There is some technical debt introduced, since all visibility controls
have been removed. This is slated for reintroduction in
#8491.

As a bonus (useful for BUILD file generation), also removed the
inconsistency in BUILD package target naming for packages in envoy.api.*
and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg.

Risk level: Low (but this will break internal builds and require BUILD
fixups to consuming projects).
Testing: bazel test //test/... @envoy_api//...

Signed-off-by: Harvey Tuch htuch@google.com

As part of envoyproxy#8082, we want to be able to (1) automatically generate BUILD
files and (2) treat packages as atomic from a "upgrade / do not upgrade"
decision perspective. This is simplified by having our BUILD targets at
package granularity, since this is what the protoxform plugin operates
on.

This PR broadens the package-level treatment that was already introduced
for Go in envoyproxy#8003 to Python and C++. This simplifies BUILD files
significantly and opens the way to automated generation.

There is some technical debt introduced, since all visibility controls
have been removed. This is slated for reintroduction in
envoyproxy#8491.

As a bonus (useful for BUILD file generation), also removed the
inconsistency in BUILD package target naming for packages in envoy.api.*
and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg.

Risk level: Low (but this will break internal builds and require BUILD
fixups to consuming projects).
Testing: bazel test //test/... @envoy_api//...

Signed-off-by: Harvey Tuch <htuch@google.com>
kyessenov
kyessenov previously approved these changes Oct 4, 2019
Copy link
Copy Markdown
Contributor

@kyessenov kyessenov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is massive! I scanned over BUILD files changes, and it matches what we discussed with per-package proto library.

Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
@htuch
Copy link
Copy Markdown
Member Author

htuch commented Oct 4, 2019

CC @yanavlasov as well, who is Google Envoy importer next week.

@htuch htuch merged commit 4e858f1 into envoyproxy:master Oct 6, 2019
@htuch htuch deleted the build-pkg-xform-gen branch October 6, 2019 00:12
nandu-vinodan pushed a commit to nandu-vinodan/envoy that referenced this pull request Oct 17, 2019
)

As part of envoyproxy#8082, we want to be able to (1) automatically generate BUILD
files and (2) treat packages as atomic from a "upgrade / do not upgrade"
decision perspective. This is simplified by having our BUILD targets at
package granularity, since this is what the protoxform plugin operates
on.

This PR broadens the package-level treatment that was already introduced
for Go in envoyproxy#8003 to Python and C++. This simplifies BUILD files
significantly and opens the way to automated generation.

There is some technical debt introduced, since all visibility controls
have been removed. This is slated for reintroduction in
envoyproxy#8491.

As a bonus (useful for BUILD file generation), also removed the
inconsistency in BUILD package target naming for packages in envoy.api.*
and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg.

Risk level: Low (but this will break internal builds and require BUILD
fixups to consuming projects).
Testing: bazel test //test/... @envoy_api//...

Signed-off-by: Harvey Tuch <htuch@google.com>
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

Successfully merging this pull request may close these issues.

3 participants