-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Document best practices for consuming autoconf/make C++ external dependencies #2814
Comments
I eagerly await progress on this front :-) |
@htuch thanks for the bug report and we love contributions :-). |
@buchgr I've added to #2792 the limitation of the |
We need to work on a better autoconf approaches in the near future. |
+1 I am having a hard time understanding this rule and how it is used. I'm trying to import gmplib which generates some headers as part of running |
Preston: nope, Try https://github.com/bazelbuild/rules_foreign_cc, they sound like what you need. |
Currently, at https://bazel.build/versions/master/docs/external.html, there's a variety of guidance for consuming external deps, but none that is suitable for handling existing C++ deps. It's certainly not scalable and even valid advice in many cases to suggest that the consuming projects of a dependency just write a BUILD file that they keep up to date on a best effort basis that parallels the existing autoconf/make based build system.
As I discovered in #2792, envoyproxy/envoy#716 and envoyproxy/envoy#747, there are a variety of approaches to encapsulating the autoconf/make process, with a
repository_rule
the cleanest way to do this. This should be a recommendation on https://bazel.build/versions/master/docs/external.html. In addition, we should have a simpler example, similar to envoyproxy/envoy#747 of how this is used. Currently, the only example in this vain isbazel/tools/cpp/cc_configure.bzl
Line 288 in ac29b78
The text was updated successfully, but these errors were encountered: