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

Use system deps for protobuf, capstone and re2 #155

Merged
merged 1 commit into from
Mar 4, 2019

Conversation

swills
Copy link
Contributor

@swills swills commented Jan 5, 2019

Note that with this system deps are used if they are found. I could add an option to only use them if requested or disabling using them if found if you like.

Also:

  • add option to disable setting build id for systems where this flag is not supported by ld
  • add option to disable installing cmake target files in case they aren't needed

I could make these separate pull requests if you like.

Also, add option to disable setting build id for systems where this flag
is not supported by ld and an option to disable installing cmake target
files in case they aren't needed.
@swills
Copy link
Contributor Author

swills commented Jan 5, 2019

Forgot to mention, this is similar in spirit to #152 but a bit of a different approach. Also, I suppose finding the system deps via non-pkg-config methods would be a good idea, but I haven't done that yet.

FWIW, I think supporting using these from the system makes sense since re2, capstone and protobuf are pretty widely packaged in various Linux distributions:

https://repology.org/metapackage/re2/versions
https://repology.org/metapackage/capstone/versions
https://repology.org/metapackage/protobuf/versions

I think having this change will make it easier to package bloaty, which isn't as widely packaged yet:

https://repology.org/metapackage/bloaty/versions

Also, it might be good to add another ci target which has these deps installed and tests with them. I can do that as part of this pull request if you like, but wanted to get feedback first.

@haberman
Copy link
Member

haberman commented Mar 4, 2019

Sorry for the slow reply. I think this is great. We can refine this over time (with more tests, searching methods, etc). but this seems like a good start.

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.

None yet

2 participants