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

Document best practices for consuming autoconf/make C++ external dependencies #2814

Closed
htuch opened this issue Apr 12, 2017 · 8 comments
Closed
Labels
P1 I'll work on this now. (Assignee required) type: documentation (cleanup) type: feature request

Comments

@htuch
Copy link

htuch commented Apr 12, 2017

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 is

# has false positives
, linked to from https://bazel.build/versions/master/docs/skylark/repository_rules.html, which is crazy complicated.

@steven-johnson
Copy link
Contributor

I eagerly await progress on this front :-)

@buchgr
Copy link
Contributor

buchgr commented Apr 13, 2017

@htuch thanks for the bug report and we love contributions :-).

@htuch
Copy link
Author

htuch commented Apr 15, 2017

@buchgr I've added to #2792 the limitation of the repository_rule approach. I'll take an action item to do a PR to link to envoyproxy/envoy#747, but it's not exactly a clean example as a result of the issues described in #2792.

@buchgr
Copy link
Contributor

buchgr commented Apr 18, 2017

cc: @mhlopko @lberki

@hlopko hlopko added the P3 We're not considering working on this, but happy to review a PR. (No assignee) label Apr 18, 2017
@dslomov dslomov added P1 I'll work on this now. (Assignee required) type: feature request and removed P3 We're not considering working on this, but happy to review a PR. (No assignee) labels Jan 11, 2018
@dslomov
Copy link
Contributor

dslomov commented Jan 11, 2018

We need to work on a better autoconf approaches in the near future.

@prestonvanloon
Copy link

+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 ./configure. Does cc_configure() achieve this? I was unable to get it to work after a brief attempt.

@hlopko
Copy link
Member

hlopko commented Oct 18, 2018

Preston: nope, cc_configure is a workspace rule that configures C++ toolchain (compiler, linker, flags...).

Try https://github.com/bazelbuild/rules_foreign_cc, they sound like what you need.

@dslomov
Copy link
Contributor

dslomov commented Mar 21, 2019

@dslomov dslomov closed this as completed Mar 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 I'll work on this now. (Assignee required) type: documentation (cleanup) type: feature request
Projects
None yet
Development

No branches or pull requests

6 participants