Dependency Management: Import CMake projects? #83
Replies: 2 comments 3 replies
-
I think there's a few ways to approach the task:
Option (1) will definitely require changes to I'm also inclined toward option (2) in particular because I have thought about making the source-dist format that For option (1), these are the following points to consider:
For option (2), there are these points:
My inclination is towards an integrated tool within
|
Beta Was this translation helpful? Give feedback.
-
Stepping back and looking more broadly on why I want this: I've found that the most successful tools usually are those which are either backwards compatible with or easily integrated with the existing infrastructure. Positive examples:
Counter examples:
IMO, if we want DDS to be broadly successful, it should be able to trivially consume CMake packages, because that gives compatibility with the current C++ ecosystem. If it really is true that very few projects cannot be adapted by the proposed tool, then that meets the "trivially consumable" requirement so it should be okay. However, I feel that it's not so simple, because those very few projects which cannot be automatically adapted are likely to be large, complicated projects which are hard requirements for some classes of users, e.g. LLVM, Qt, etc. It is my impression that there are enough of these projects that it is infeasible to provide them all in a central DDS repo. |
Beta Was this translation helpful? Give feedback.
-
I know this goes against the philosophy of DDS, but the reality is that there are a lot of dependencies out there, and it's a lot of work to write a DDS port / porting script for every library we want to use. Furthermore, sometimes the project does some complex things with the build system that makes it difficult to see how to translate it to the structure DDS requires. Understanding this, what if DDS was able to consume projects with a CMake build system?
What I mean by this is that we could have DDS invoke CMake to build the dependencies, extracting information from specified CMake targets. The user would still have to add a DDS repo pointing to the CMake project, but it could contain some metadata that tells DDS how to invoke CMake to build the project with consistent flags.
Although this is a complex solution to the problem, the benefit is that it would allow the easy consumption of most libraries even if they were not ported to the DDS style.
Beta Was this translation helpful? Give feedback.
All reactions