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

Consider embedding libraries in source tree #735

Open
eteran opened this issue Dec 4, 2019 · 5 comments
Open

Consider embedding libraries in source tree #735

eteran opened this issue Dec 4, 2019 · 5 comments
Labels

Comments

@eteran
Copy link
Owner

@eteran eteran commented Dec 4, 2019

I was thinking, we basically have 3 uncommon dependencies.

  1. Capstone
  2. gdtoa-desktop
  3. libdouble-conversion

These are all relatively speaking, small. It may be reasonable to have a libs directory which contains copies of these projects which we would use if they are not installed system-wide, or perhaps always?

This lets us have a simpler dependency process, potentially lock in versions we are sensitive to, and make these dependencies unconditional, which is just simpler.

@10110111 Thoughts?

@eteran eteran added the enhancement label Dec 4, 2019
@10110111

This comment has been minimized.

Copy link
Contributor

@10110111 10110111 commented Dec 4, 2019

I wouldn't say libdouble-conversion is uncommon: it's used by Qt, at least in Debian, see libqt5core5a.
Capstone is also long packaged (and I don't actually install it from source on Ubuntu 18.04 — just libcapstone-dev).
The only package not common is gdtoa-desktop, since it's only recently appeared. But I guess once EDB has been released, and the distros start updating their packages, it will also get packaged.

So in summary, I don't think it's useful to bundle these libraries with EDB source, at least not all of them.

@eteran

This comment has been minimized.

Copy link
Owner Author

@eteran eteran commented Dec 4, 2019

Fair enough points. I agree about libdouble-conversion for certain; I had forgotten that Qt uses it.

Regarding Capstone, I'm kinda in the middle on it. Not because it isn't routinely packaged, but the version of it available from repos is a bit unreliable.

For example, I ran into errors doing the ARM32 build testing because one system had capstone 4 and another had capstone 3. If we had it baked in, we could just say "we use capstone 4 always".

But if I'm being honest, gdtoa-desktop really is the motivator for this idea. I've never had it installed, and I've never seen it available from any package managers. It's a little bit optimistic to say that edb will cause distros to start packaging it since it's a "soft" dependency. edb "works" just fine without it, they may not even notice it's an optional dep if they don't really read the CMake warnings.

So yea, I agree with your "not all of them" assessment.

@10110111

This comment has been minimized.

Copy link
Contributor

@10110111 10110111 commented Dec 4, 2019

Well, gdtoa-desktop might indeed be a candidate for bundling. Especially if GCC finally implements std::to_chars for long double by the time EDB switches to C++17 or higher, in which case we could silently remove this dependency completely.

@eteran

This comment has been minimized.

Copy link
Owner Author

@eteran eteran commented Dec 4, 2019

Totally agree. So I may move forward with the gdtoa-desktop embedding sometime soon. I assume the copy in your repo is an appropriate source for it?

@10110111

This comment has been minimized.

Copy link
Contributor

@10110111 10110111 commented Dec 4, 2019

Yeah, it's the original place to find it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.