# best practice directory structure with libraries

**URL:** https://discourse.cmake.org/t/best-practice-directory-structure-with-libraries/7345
**Category:** Usage
**Created:** [January 28, 2023, 7:47pm UTC](https://discourse.cmake.org/t/best-practice-directory-structure-with-libraries/7345 "2023-01-28T19:47:50Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![parrst](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/p/3da27b/32.png) [@parrst](https://discourse.cmake.org/u/parrst)
#### Post date: [January 28, 2023, 7:47pm UTC](https://discourse.cmake.org/t/best-practice-directory-structure-with-libraries/7345/1 "2023-01-28T19:47:50Z")

</div>

I have done VERY little in the way of compiled programing and having to learn the likes of cmake is part of why. For now the context of my questions are all Raspberry Pico projects. I may delve into Pi or windows later, but for now just Pico. I have a series of questions, but will start with this one…

I have seen several ways that seem to organize libraries such as in the pico sdk that are like this:

-library(one library in a folder of several libraries)  
code.c  
CMakeLists.txt  
-include (nothing in include but the some\_name folder)  
-some\_name  
code.h

Why bury the .h file so deep. Also the CMakeLists.txt in the library root has target\_include\_directories(pico\_stdio INTERFACE ${CMAKE\_CURRENT\_LIST\_DIR}/include). There is nothing but a folder in include, so I assume target\_include\_directories includes all sub directories as well. Also why is the keyword INTERFACE used? Is that because all pico libraries are interfaces?

Bob

---

<div class="post-metadata">

### Author: ![parrst](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/p/3da27b/32.png) [@parrst](https://discourse.cmake.org/u/parrst)
#### Post date: [January 28, 2023, 7:56pm UTC](https://discourse.cmake.org/t/best-practice-directory-structure-with-libraries/7345/2 "2023-01-28T19:56:43Z")

</div>

I guess as a follow up would this be a best practice (yes I am sure there are as many thoughts on this as there are people, but looking for what us usual, and will lead into add\_library type cmake commands)

Is this a good way to organize my code?

-Pico  
-pico-sdk  
-Projects  
-My libraries  
-LCD library  
-NRF library  
-My projects  
-project 1  
-project 2

And so on.

---

<div class="post-metadata">

### Author: ![ClausKlein](https://discourse.cmake.org/user_avatar/discourse.cmake.org/clausklein/32/352_2.png) [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [January 28, 2023, 8:59pm UTC](https://discourse.cmake.org/t/best-practice-directory-structure-with-libraries/7345/3 "2023-01-28T20:59:53Z")

</div>

Do you now this repos?

- [C++ Best Practices · GitHub](https://github.com/cpp-best-practices/)
- [GitHub - aminya/cpp\_vcpkg\_project: A production-ready C++ project made with vcpkg](https://github.com/aminya/cpp_vcpkg_project)
- [GitHub - TheLartians/ModernCppStarter: 🚀 Kick-start your C++! A template for modern C++ projects using CMake, CI, code coverage, clang-format, reproducible dependency management and much more.](https://github.com/TheLartians/ModernCppStarter)
- [GitHub - friendlyanon/cmake-init: The missing CMake project initializer](https://github.com/friendlyanon/cmake-init)

---

<div class="post-metadata">

### Author: ![parrst](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/p/3da27b/32.png) [@parrst](https://discourse.cmake.org/u/parrst)
#### Post date: [January 29, 2023, 12:01am UTC](https://discourse.cmake.org/t/best-practice-directory-structure-with-libraries/7345/4 "2023-01-29T00:01:43Z")

</div>

Will check them out. Thank you.

Bob

---

<div class="post-metadata">

### Author: ![markdewit\_ies](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/m/e95f7d/32.png) [@markdewit\_ies](https://discourse.cmake.org/u/markdewit_ies)
#### Post date: [February 3, 2023, 1:07pm UTC](https://discourse.cmake.org/t/best-practice-directory-structure-with-libraries/7345/5 "2023-02-03T13:07:45Z")

</div>

To answer directly your question on the header structure, I also have:  
include → some\_name → my\_header.h

The main reason for this particular structure is that the include statement in the source code becomes:  
#include \<some\_name/my\_header.h\>

and this helps to document which particular library or module the header comes from, and helps to avoid naming clashes between header files.
