### Author:  [@jcfr](https://discourse.cmake.org/u/jcfr)
#### Post date: [June 10, 2020, 11:32pm UTC](https://discourse.cmake.org/t/correct-way-to-use-third-party-libraries-in-cmake-project/1368/1 "2020-06-10T23:32:20Z")
A while back I answered this question on stackoverflow, since it is getting up voted regularly, I am also cross-posting here:
>
It may also help answer questions in this thread:
- [Best practices on finding third party libraries for a project?](https://discourse.cmake.org/t/best-practices-on-finding-third-party-libraries-for-a-project/170)
Cc: @thomthom
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 11, 2020, 1:16am UTC](https://discourse.cmake.org/t/correct-way-to-use-third-party-libraries-in-cmake-project/1368/2 "2020-06-11T01:16:25Z")
I don’t have time to do too much detail here right now, but my general order of preference:
- always find an external version
- PRO: easy to maintain
- CON: harder for users to build your software, especially if the dep is not available via the typical packaging routes (Linux distro, Anaconda, HomeBrew, MacPorts)
- superbuild which builds your deps and your projects (`ExternalProject`)
- Don’t try to do `ExternalProject_add` for your deps in your main project. The two approaches are like oil and water.
- PRO: users have a turn-key solution to building your software, packaging environments can ignore the superbuild and provide dependencies the way they can/want.
- CON: PITA to maintain outside of well-tested environments, fragile, and can make development harder
- embedding/vendoring
- PRO: Easy for anyone to build your code
- CON: Linux distros and other packaging setups will be unhappy without conditional support for the first solution here. Mangling symbols and library names is a real PITA to maintain. Tends to stagnate and ship old versions without vigilance.
- monorepo
- This moves up the list for me if you are building a _product_ that is self-contained. Keep away for “frameworks”, libraries, or “platforms”.
- PRO: You know exactly what you’re building.
- CON: Users get only what you ship (arguably also a PRO, but unless you support the cross product of targets, someone is going to be unhappy).
For the first, look at any standard Unix package (more or less). The second is used by ParaView to make sure its packages are consistent. The third is done by VTK and ParaView. Note that just doing `FetchContent` for your dependencies without mangling symbols, library names, and include paths (if an SDK is supported) is asking for trouble if you ship libraries loadable outside your project (plugins, SDKs) or load plugins from outside your project at runtime (plugins) if anyone brings in one of your dependencies by another route. The last is Chrome, many macOS and Windows applications, and other store-like deployment targets (Steam, Google Play, F-Droid, Apple’s App Store, Windows Store, etc.).
Third party projects are hard in C++ because there’s no packaging system and even if there were, getting people to agree on its properties at this point is nigh impossible. All three of the solutions above are double edged swords. Pick your poison with care.
---
### Author:  [@jwm](https://discourse.cmake.org/u/jwm)
#### Post date: [June 11, 2020, 2:20am UTC](https://discourse.cmake.org/t/correct-way-to-use-third-party-libraries-in-cmake-project/1368/3 "2020-06-11T02:20:26Z")
That SO post is **so** close to answering my questions. In my post [The Zen of integrating 3rd party packages](https://discourse.cmake.org/t/the-zen-of-integrating-3rd-party-packages/1318/2) I have a package that is so bad. Unfortunately, the package is _very_ badly maintained.
I got it to build using ExternalProject, but other components need a little help finding the headers and library.
---
### Author:  [@phread](https://discourse.cmake.org/u/phread)
#### Post date: [July 19, 2022, 5:18pm UTC](https://discourse.cmake.org/t/correct-way-to-use-third-party-libraries-in-cmake-project/1368/4 "2022-07-19T17:18:03Z")
Any updates for this based on the “Dependency Provider” capability added in v3.24?
- [https://cmake.org/cmake/help/v3.24/guide/using-dependencies/index.html#dependency-providers](https://cmake.org/cmake/help/v3.24/guide/using-dependencies/index.html#dependency-providers)
- [https://gitlab.kitware.com/cmake/cmake/-/merge\_requests/7276](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7276)
- [https://gitlab.kitware.com/cmake/cmake/-/issues/22619](https://gitlab.kitware.com/cmake/cmake/-/issues/22619)
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 19, 2022, 9:32pm UTC](https://discourse.cmake.org/t/correct-way-to-use-third-party-libraries-in-cmake-project/1368/5 "2022-07-19T21:32:52Z")
Cc: @craig.scott
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [July 20, 2022, 1:15am UTC](https://discourse.cmake.org/t/correct-way-to-use-third-party-libraries-in-cmake-project/1368/6 "2022-07-20T01:15:30Z")
I don’t intend to reply here. You may want to keep an eye on [this post](https://discourse.cmake.org/t/fetchcontent-in-dependency-management/6038) though, where I do intend to reply when I get a chance (will be some weeks away yet).
---
### Author:  [@bcmkakme](https://discourse.cmake.org/u/bcmkakme)
#### Post date: [December 5, 2022, 11:02am UTC](https://discourse.cmake.org/t/correct-way-to-use-third-party-libraries-in-cmake-project/1368/7 "2022-12-05T11:02:52Z")
The post at [CMake: How to build external projects and include their targets - Stack Overflow](https://stackoverflow.com/questions/15175318/cmake-how-to-build-external-projects-and-include-their-targets) is very helpful for using `ExternalProject`