# STATIC LIBARY - with an outside header file

**URL:** <https://discourse.cmake.org/t/static-libary-with-an-outside-header-file/11498>\
**Category:** Code\
**Created:** [August 21, 2024, 10:26pm UTC](https://discourse.cmake.org/t/static-libary-with-an-outside-header-file/11498 "2024-08-21T22:26:21Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![duaneellis\_inno](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/d/f04885/32.png) [@duaneellis\_inno](https://discourse.cmake.org/u/duaneellis_inno)\
**Post date:** [August 21, 2024, 10:26pm UTC](https://discourse.cmake.org/t/static-libary-with-an-outside-header-file/11498/1 "2024-08-21T22:26:21Z")

</div>

Generally - the idea as I understand is this:

A static library should be very self contained.

But in my case I can’t do that.

Reason: In an embedded target, I need to highly taylor the static library for the end application.

A classic example is found in FreeRTOS  
The specific file is: FreeRTOSConfig.h

A link to one example is here:

> <https://github.com/Infineon/freertos/blob/master/Source/portable/COMPONENT_CM33/FreeRTOSConfig.h>

(Another example is LWIP, it uses the file: “lwipopts.h”)

The intent is each application provides this TAYLORING header file so it can taylor the library to the specific needs of the application.

In my case I have 7 applications (across 2 CPU cores and 7 boards) - each has a different tayloring header file for FreeRTOS and LWIP.

I want to build the “libFreeRTOS” via “add\_lib…” Each applciation toplevel CMakeLists.txt would/should just “add\_subdirectory” - for the LibFreeRTOS.

But the method Cmake sort of desires is the LibFreeRTOS is very self contained, ie: ALL Headers it requires are local to the project which is not true for me It depends on the board I am targeting.

Any suggstions on how I should handle this in the CMAKE Way?  
Rather then my bastardized way of jamming an include path down the tools mouth?

NOTE: In addition to a standard #include - for compile time configuration, another package makes use of the GCC option: ‘–include’ - which forces the compiler to read a specific file in front of all other files it compiles, so I need to have a means to supply BOTH to the libraries being built.

---

<div class="post-metadata">

**Author:** ![ferdnyc](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ferdnyc/32/267_2.png) [@ferdnyc](https://discourse.cmake.org/u/ferdnyc)\
**Post date:** [August 22, 2024, 11:48am UTC](https://discourse.cmake.org/t/static-libary-with-an-outside-header-file/11498/2 "2024-08-22T11:48:22Z")

</div>

> [@duaneellis\_inno](#):
>
> A static library should be very self contained.

Well, yes, but there’s no such thing as a static library so self-contained that it doesn’t require header files. They’re how a C/C++ library defines its API, both during its own build and for external users of the library. A library (static or shared) in a C/C++ program consists of the binary compiled object archive _and_ the corresponding header files.

> [@duaneellis\_inno](#):
>
> The intent is each application provides this TAYLORING header file so it can taylor the library to the specific needs of the application.

Yeah, FreeRTOS are doing some maybe-“clever” things there, with that customization-by-preconfigured-header thing. Still, if it works, then great.

Reordering two of your following statements…

> [@duaneellis\_inno](#):
>
> But the method Cmake sort of desires is the LibFreeRTOS is very self contained, ie: ALL Headers it requires are local to the project which is not true for me It depends on the board I am targeting.

That’s not a requirement at all. All CMake, or any other build system, needs is for the necessary headers be found in the include paths that it passes to the compiler when building the library. Your own code then needs to be built with those same include paths.

> [@duaneellis\_inno](#):
>
> I want to build the “libFreeRTOS” via “add\_lib…” Each applciation toplevel CMakeLists.txt would/should just “add\_subdirectory” - for the LibFreeRTOS.

That’s certainly a possibility, though the need for a configuration header complicates things a tiny bit. Still, it’s not an unworkable goal. There are a couple of ways you could go:

1. Set up the `CMakeLists.txt` inside the `libFreeRTOS` subdirectory to expect a variable, say `FREERTOS_CONFIG_DIR`, that points to the location of the `configFreeRTOS.h` file that should be used for the particular build. Have it add that location to the include paths when building the library. Your outer application `CMakeLists.txt` can provide that variable, or you can set it on the `cmake` command line when configuring the project by adding `-DFREERTOS_CONFIG_DIR=<path>` to the arguments.

2. Or, you can make a copy of the `libFreeRTOS` source directory, place the specific `configFreeRTOS.h` you need inside it, and have the library pick up the include from inside its own source dir. That seems more like what the FreeRTOS team is expecting, that each different configuration will be integrated into its own copy of the library sources. Especially since the header has to be _modified_ before it can be used, making it plug-and-play switchable really doesn’t seem to be a priority. Having a customized source tree definitely makes the build easier, at a sacrifice of a little disk space/redundancy.