# Best practice to configure libraries
**URL:** https://discourse.cmake.org/t/best-practice-to-configure-libraries/10083
**Category:** Usage
**Created:** [February 14, 2024, 11:37am UTC](https://discourse.cmake.org/t/best-practice-to-configure-libraries/10083 "2024-02-14T11:37:07Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@LarryOates](https://discourse.cmake.org/u/LarryOates)
#### Post date: [February 14, 2024, 11:37am UTC](https://discourse.cmake.org/t/best-practice-to-configure-libraries/10083/1 "2024-02-14T11:37:07Z")
I have a project that includes a library which I have written which can be reused in multiple projects. This library uses header files to configure it’s self depending on what the application requires. I am unsure what the best practice for this is - I want the library to be portable and to tell future users how to use it (even with minimum CMake experience)
As is the Library is added to the project as a git submodule and it’s is added via add\_subdirectory in the main project. My current thinking is to have templates of the the config headers contained in the library which will be copied to a config folder in the main project (so the user can configure it and the changes will be saved in the main projects git). The submodule library’s CMakeLists.txt will then add these files to a interface library (as it’s headers only) and link this privately to the submodule library.
Are there any better ways to do this?
Thanks,
Larry
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [February 14, 2024, 11:12pm UTC](https://discourse.cmake.org/t/best-practice-to-configure-libraries/10083/2 "2024-02-14T23:12:00Z")
### I would not use git submodule!
Try to use `FetchContents` or `CPM.cmake`.
An example for an header only lib may found here: [GitHub - ClausKlein/Observe: 📣 Hey listen! A simple general-purpose event-listener system for C++17.](https://github.com/ClausKlein/Observe?tab=readme-ov-file#installation-and-usage)
---
### Author:  [@LarryOates](https://discourse.cmake.org/u/LarryOates)
#### Post date: [February 15, 2024, 11:54am UTC](https://discourse.cmake.org/t/best-practice-to-configure-libraries/10083/3 "2024-02-15T11:54:44Z")
Hi Clause,
Thanks for your reply.
What is your reason for preferring these over submodules? Is it just so there is no dependency on git/submodules? The advantage I see with submodules is that the libraries can be developed from within a consuming project then the changes can be easily pushed.
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [February 15, 2024, 12:09pm UTC](https://discourse.cmake.org/t/best-practice-to-configure-libraries/10083/4 "2024-02-15T12:09:41Z")
> [@LarryOates](#):
>
> What is your reason for preferring these over submodules?
[what-are-the-advantages-and-disadvantages-for-the-use-of-git-submodules](https://stackoverflow.com/questions/77383741/what-are-the-advantages-and-disadvantages-for-the-use-of-git-submodules)
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [February 15, 2024, 12:33pm UTC](https://discourse.cmake.org/t/best-practice-to-configure-libraries/10083/5 "2024-02-15T12:33:55Z")
### There are 2 main reason to do it like my example:
The first one:
- The project is desined to be used as subproject and as standalone project.
- And the standalone library may be installed and imported with find\_package().
- Too, it is guaranteed, that the exported package in usable without errors, see test/CMakeLists.txt.
The second one:
- With `CPM.cmake`, you may use a central cache for the cloned external projects.
- Wo it is very fast, if found in `cpm_source_cache`.
- And you have the option to use local installed packages if found (`CPM_USE_LOCAL_PACKAGES`).
see [CPM.cmake options](https://github.com/cpm-cmake/CPM.cmake/tree/master?tab=readme-ov-file#cpm_source_cache)