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

Jump to bottom

Make cgo use standard C/C++ toolchain actions #1742

Closed
jayconrod opened this issue Oct 1, 2018 · 2 comments
Closed

Make cgo use standard C/C++ toolchain actions #1742

jayconrod opened this issue Oct 1, 2018 · 2 comments
Labels
cgo enhancement

Comments

@jayconrod
Copy link
Contributor

Currently, when cgo = True on go_library, go_binary, or go_test, we create a large graph of rules.

  • There is an internal _cgo_codegen rule that generates pure C and pure Go code.
  • Go code is built with go_library.
  • The C code is compiled with cc_library and cc_binary. Objects are extracted out of the static library and packed into the .a file produced by go_library.
  • Lots of other details.

This graph is repeated for every configuration that could affect the evaluation of build tags, so it has a significant overhead in analysis time. It's also hostile to bazel query, since there are a lot of targets that are less in the what to build category and more in the how to build it.

Recently, Bazel exposed a lot more information about the C/C++ toolchain to Starlark rules. We should be able to incorporate cgo directly into the analysis code that implements go_library, go_binary, and go_test. We should not need separate rules for code generation or C/C++ compilation.

It may still be necessary to use objc_library to compile Objective C code, since the Objective C toolchain is not exposed.
jayconrod pushed a commit to jayconrod/rules_go that referenced this issue Oct 15, 2018
Migrate to cc_common for collecting C/C++ paths and options
bb01735 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes bazelbuild#1744
Related bazelbuild#1742
@jayconrod jayconrod mentioned this issue Oct 15, 2018
Merged
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
6fa12b1 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
c414e7c 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
3c97a6a 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
92bafce 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
defc130 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
89603ad 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
af8850e 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
jayconrod added a commit that referenced this issue Oct 16, 2018
@jayconrod
Migrate to cc_common for collecting C/C++ paths and options (#1768)
dde4865 
Previously, the internal go_context_data read C/C++ paths and options
from the CcToolchainInfo provider. Most of the fields in this provider
come from CROSSTOOL and will be removed in Bazel 0.20.0 (see
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#disable-legacy-c-toolchain-api).

This change migrates us to use the new cc_common module. This change
is intended to be a quick fix to be backported to old release
branches, so no architectural changes are made.

Fixes #1744
Related #1742
@jmhodges
Copy link
Contributor

I'm not sure what's left on this ticket. I think maybe the code that needed this was finally deleted in d31ac79 ?

@jayconrod
Copy link
Contributor Author

Yeah, this can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
cgo enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jmhodges @jayconrod