-
Notifications
You must be signed in to change notification settings - Fork 60
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
Remove vendored dependencies #125
Comments
This is relevant: https://gitlab.kitware.com/cmake/cmake/-/issues/20511 |
Hi @rubendibattista and @ggange, Would it make more since just to use git submodules and the download/installation to our build config (if Eigen is not found)? I agree that there should be a better way to handle this then the way we are now. As for Catch2, personally, I would prefer just to stick the single header (which has it's copyright info) in the tests directory and that's it. I think this is the simplest way forward IMO. |
Ehi @jbscoggi, that would not solve the problem with dependency propagation when coupling Instead of doing that, what about just, you know, asking users to I think I might be able to persist the installation information of Catch2 it's a less pressing need since |
This is also related: https://stackoverflow.com/questions/30987311/exporting-an-imported-library |
After a private conversation with @ggange, I think that Mutation++ should not vendor the dependencies.
I explain why: you are someone that wants to couple
mutation++
with your own solver code. Let'assume you are usingcmake
also for your solver.You compile
mutation++
using the instructions provided in the documentation, but you don't have Eigen installed system-wide. Then the current situation will use the one vendored inthird_party
. So far so good.The problems start to appear when you then
find_package(mutation++)
in your code. SinceEigen
is aPUBLIC
dependency ofmutation++
, thefind_dependency
in the configure file of mutation++ will try to find Eigen without luck, and it will complain.The hacky solution then would be to add the
third_party
directory intoCMAKE_MODULE_PREFIX
and writing aFindEigen3.cmake
(taking it maybe from this repository) or install Eigen system wide, with potential version mismatch problems.IMHO what should happen is that whoever wants to build
mutation++
should have Eigen installed separately, hopefully with your package manager. That means if you can buildmutation++
you can also build whatever depends on it. Further advantages are that we do not have to ship theFindEigen3.cmake
since modern installations of Eigen will ship theEigenConfig.cmake
so it will be captured by cmake automatically and natively.The need for
Catch2
is less urgent, since basically nobody uses it apart from CI (and I think tests fails in new versions...)What do you think?
The text was updated successfully, but these errors were encountered: