# Tips on project organization

**URL:** <https://discourse.cmake.org/t/tips-on-project-organization/13627>\
**Category:** Code\
**Created:** [February 24, 2025, 10:26pm UTC](https://discourse.cmake.org/t/tips-on-project-organization/13627 "2025-02-24T22:26:21Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![eriols](https://discourse.cmake.org/user_avatar/discourse.cmake.org/eriols/32/945_2.png) [@eriols](https://discourse.cmake.org/u/eriols)\
**Post date:** [February 24, 2025, 10:26pm UTC](https://discourse.cmake.org/t/tips-on-project-organization/13627/1 "2025-02-24T22:26:21Z")

</div>

Sorry for an open-ended question, but I’m interested in tips on how to organize a medium sized cmake project in a structed way (or tips of good cmake projects to be inspired by).

More concretely it seems a lot of projects are doing very much in one big CMakeLists.txt and I’d prefer to work towards dividing a large file up into eg functions and macros or modules even, just like in a normal HLL.  
Here though I find cmake working a bit against this by - afaik - not providing much help in terms of interfaces to modules, functions etc.  
Ideally I’d like a very small main file, maybe:

```opts
defs = store_compile_defs(opts)
build_lib(opts, defs)
if tests; build_tests
if docs_requested; create_docs 
etc...

```

Eg sometimes I see people putting options handling in a separate module, but then this is “just” a block of code that is moved someplace else. There is no interface where one would do `my_options = get_options()` or such; still something working with public data and no encapsulation.  
Another example I have is a very long macro storing compiler defines in a list (as I need them to 1) build my project 2) as input to doxygen and 3) to unifdef public headers). Is putting this in a macro in a helper module of sorts the best I can do, or is there something better?