# Build is compiling against system include directory when it should be compiling against sub-project include directory

**URL:** https://discourse.cmake.org/t/build-is-compiling-against-system-include-directory-when-it-should-be-compiling-against-sub-project-include-directory/9211
**Category:** Usage
**Tags:** os:macos
**Created:** [October 17, 2023, 6:28pm UTC](https://discourse.cmake.org/t/build-is-compiling-against-system-include-directory-when-it-should-be-compiling-against-sub-project-include-directory/9211 "2023-10-17T18:28:19Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![boxerab](https://discourse.cmake.org/user_avatar/discourse.cmake.org/boxerab/32/718_2.png) [@boxerab](https://discourse.cmake.org/u/boxerab)
#### Post date: [October 17, 2023, 6:28pm UTC](https://discourse.cmake.org/t/build-is-compiling-against-system-include-directory-when-it-should-be-compiling-against-sub-project-include-directory/9211/1 "2023-10-17T18:28:19Z")

</div>

This is a reported issue on MacOS 13.3 Here is the issue on github for more context

> <https://github.com/GrokImageCompression/grok/issues/348>
>
> Compile the project from source will complain like below
> \`\`\`
> /usr/local/includ…e/hwy/targets.h:303:44: error: use of undeclared identifier 'HWY\_AVX3\_ZEN4'
> /usr/local/include/hwy/targets.h:171:28: note: expanded from macro 'HWY\_CHOSEN\_TARGET\_MASK\_TARGETS'
> (HWY\_CHOSEN\_TARGET\_SHIFT(HWY\_TARGETS) | HWY\_CHOSEN\_TARGET\_MASK\_SCALAR | 1LL)
> ^
> /usr/local/include/hwy/detect\_targets.h:468:58: note: expanded from macro 'HWY\_TARGETS'
> (HWY\_ATTAINABLE\_TARGETS & ((HWY\_STATIC\_TARGET - 1LL) | HWY\_STATIC\_TARGET))
> ^
> /usr/local/include/hwy/detect\_targets.h:374:28: note: expanded from macro 'HWY\_STATIC\_TARGET'
> \#define HWY\_STATIC\_TARGET (HWY\_ENABLED\_BASELINE & -HWY\_ENABLED\_BASELINE)
> ^
> /usr/local/include/hwy/detect\_targets.h:367:30: note: expanded from macro 'HWY\_ENABLED\_BASELINE'
> \#define HWY\_ENABLED\_BASELINE HWY\_ENABLED(HWY\_BASELINE\_TARGETS)
> ^
> /usr/local/include/hwy/detect\_targets.h:170:19: note: expanded from macro 'HWY\_ENABLED'
> ((targets) & ~((HWY\_DISABLED\_TARGETS) | (HWY\_BROKEN\_TARGETS)))
> \`\`\`
> The system is macos and it has highway 1.0.3. So I have to uninstall the highway
> 
> Then errors about lcms2 pop out.
> \`\`\`
> /usr/local/include/lcms2.h:1291:44: error: ISO C++17 does not allow 'register' storage class specifier \[-Wregister\]
> typedef cmsInt32Number (\* cmsSAMPLER16) (CMSREGISTER const cmsUInt16Number In\[\],
> ^ ~~~~~~~~~~~
> /usr/local/include/lcms2.h:158:23: note: expanded from macro 'CMSREGISTER'
> \# define CMSREGISTER register
> ^
> /usr/local/include/lcms2.h:1292:44: error: ISO C++17 does not allow 'register' storage class specifier \[-Wregister\]
> CMSREGISTER cmsUInt16Number Out\[\],
> ^ ~~~~~~~~~~~
> /usr/local/include/lcms2.h:158:23: note: expanded from macro 'CMSREGISTER'
> \# define CMSREGISTER register
> ^
> /usr/local/include/lcms2.h:1293:44: error: ISO C++17 does not allow 'register' storage class specifier \[-Wregister\]
> CMSREGISTER void \* Cargo);
> ^ ~~~~~~~~~~~
> /usr/local/include/lcms2.h:158:23: note: expanded from macro 'CMSREGISTER'
> \# define CMSREGISTER register
> ^
> /usr/local/include/lcms2.h:1295:44: error: ISO C++17 does not allow 'register' storage class specifier \[-Wregister\]
> typedef cmsInt32Number (\* cmsSAMPLERFLOAT)(CMSREGISTER const cmsFloat32Number In\[\],
> ^ ~~~~~~~~~~~
> /usr/local/include/lcms2.h:158:23: note: expanded from macro 'CMSREGISTER'
> \# define CMSREGISTER register
> ^
> /usr/local/include/lcms2.h:1296:44: error: ISO C++17 does not allow 'register' storage class specifier \[-Wregister\]
> CMSREGISTER cmsFloat32Number Out\[\],
> ^ ~~~~~~~~~~~
> /usr/local/include/lcms2.h:158:23: note: expanded from macro 'CMSREGISTER'
> \# define CMSREGISTER register
> ^
> /usr/local/include/lcms2.h:1297:44: error: ISO C++17 does not allow 'register' storage class specifier \[-Wregister\]
> CMSREGISTER void \* Cargo);
> ^ ~~~~~~~~~~~
> /usr/local/include/lcms2.h:158:23: note: expanded from macro 'CMSREGISTER'
> \# define CMSREGISTER register
> \`\`\`

My project [grok](https://github.com/GrokImageCompression/grok) uses another library, [highway](https://github.com/google/highway), using these commands:

```auto
set(HWY_ENABLE_EXAMPLES OFF CACHE BOOL "Enable HWY examples")
set(HWY_ENABLE_CONTRIB OFF CACHE BOOL "Enable HWY contrib")
set(HWY_ENABLE_INSTALL OFF CACHE BOOL "Enable HWY install")
set(HWY_FORCE_STATIC_LIBS ON CACHE BOOL "Enable HWY force static libs")
set(INSTALL_GTEST OFF CACHE BOOL "Install GTest")
set(HWY_ENABLE_TESTS OFF CACHE BOOL "Disable tests")
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/highway EXCLUDE_FROM_ALL)

```

and then

```auto
target_include_directories(${GROK_CORE_NAME} PRIVATE $<TARGET_PROPERTY:hwy,INTERFACE_INCLUDE_DIRECTORIES>)

```

However, if an older version of highway is installed via `brew install highway`,  
then compile fails due to usage of installed include directory rather than source include directory for highway. Uninstalling brew highway allows the compile to succeed.

This is not a problem on Linux.

I’ve tried a number of changes, but currently at a loss as to how to fix .

`

---

<div class="post-metadata">

### Author: ![buildSystemPerson](https://discourse.cmake.org/user_avatar/discourse.cmake.org/buildsystemperson/32/2851_2.png) [@buildSystemPerson](https://discourse.cmake.org/u/buildSystemPerson)
#### Post date: [October 17, 2023, 7:40pm UTC](https://discourse.cmake.org/t/build-is-compiling-against-system-include-directory-when-it-should-be-compiling-against-sub-project-include-directory/9211/2 "2023-10-17T19:40:46Z")

</div>

> target\_include\_directories(${GROK\_CORE\_NAME} PRIVATE $\<TARGET\_PROPERTY:hwy,INTERFACE\_INCLUDE\_DIRECTORIES\>)

Why are you adding the include directory like this?

Just linking the library should be enough.

```auto
target_link_libraries(${GROK_CORE_NAME} PRIVATE hwy)

```

`hwy` properly makes it’s include directories with the [PUBLIC](https://github.com/google/highway/blob/b17c0e474c3cb17c95f8f59bd4f4da1f244b4b1c/CMakeLists.txt#L340C27-L340C32). So linking against the provided target should be sufficient.

---

<div class="post-metadata">

### Author: ![boxerab](https://discourse.cmake.org/user_avatar/discourse.cmake.org/boxerab/32/718_2.png) [@boxerab](https://discourse.cmake.org/u/boxerab)
#### Post date: [October 17, 2023, 7:57pm UTC](https://discourse.cmake.org/t/build-is-compiling-against-system-include-directory-when-it-should-be-compiling-against-sub-project-include-directory/9211/3 "2023-10-17T19:57:53Z")

</div>

> [@buildSystemPerson](#):
>
> Why are you adding the include directory like this?
> 
> Just linking the library should be enough.
> 
> ```auto
> target_link_libraries(${GROK_CORE_NAME} PRIVATE hwy)
> 
> ```

Yes, I just added that line to make “extra sure” I was compiling against the source include directory, but it made no difference in fact. Still mystified.

---

<div class="post-metadata">

### Author: ![boxerab](https://discourse.cmake.org/user_avatar/discourse.cmake.org/boxerab/32/718_2.png) [@boxerab](https://discourse.cmake.org/u/boxerab)
#### Post date: [October 19, 2023, 1:28pm UTC](https://discourse.cmake.org/t/build-is-compiling-against-system-include-directory-when-it-should-be-compiling-against-sub-project-include-directory/9211/4 "2023-10-19T13:28:02Z")

</div>

Looks like this was a red herring - issue went away after user deleted and re-configured their build folder.