# Problem with \*general\* library name
**URL:** https://discourse.cmake.org/t/problem-with-general-library-name/15559
**Category:** Usage
**Created:** [March 14, 2026, 1:26am UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559 "2026-03-14T01:26:21Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@vvs31415](https://discourse.cmake.org/u/vvs31415)
#### Post date: [March 14, 2026, 1:26am UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/1 "2026-03-14T01:26:21Z")
The following project builds successfully:
> // foo.cpp
> void foo() {}
>
> // bar.cpp
> void foo();
> void main() { foo(); }
>
> project(p)
> add\_library(general foo.cpp)
> link\_libraries(general)
> add\_executable(foo bar.cpp)
Let us modernize it with **target\_link\_libraries** :
> project(p)
> add\_library(general foo.cpp)
> add\_executable(foo bar.cpp)
> target\_link\_libraries(foo general)
We have an error:
> CMake Error at CMakeLists.txt:4 (target\_link\_libraries):
> The “general” argument must be followed by a library.
The problem is that **general** is a keyword within **target\_link\_libraries()**
Is there a way to escape the library name?
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [March 14, 2026, 8:42am UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/2 "2026-03-14T08:42:59Z")
> [@vvs31415](#):
>
> target\_link\_libraries
see [syntax for target\_link\_libraries](https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents)
p.s. which version of `cmake` do you use?
---
### Author:  [@vvs31415](https://discourse.cmake.org/u/vvs31415)
#### Post date: [March 14, 2026, 1:48pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/3 "2026-03-14T13:48:04Z")
OK, this seems to work:
```auto
target_link_libraries(foo $<1:general>)
```
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [March 14, 2026, 2:13pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/4 "2026-03-14T14:13:50Z")
@ben.boeckel is this a bug or a feature?
see [https://cmake.org/cmake/help/latest/command/link\_libraries.html](https://cmake.org/cmake/help/latest/command/link_libraries.html)
`general, debug, optimized` are reserved, not usable as library names?
```cmake
cmake_minimum_required(VERSION 4.2...4.3)
project(p LANGUAGES CXX)
add_library(optimized STATIC)
target_sources(optimized PRIVATE foo.cpp)
add_executable(bar bar.cpp)
target_link_libraries(bar PRIVATE optimized)
```
---
### Author:  [@vvs31415](https://discourse.cmake.org/u/vvs31415)
#### Post date: [March 14, 2026, 2:31pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/5 "2026-03-14T14:31:58Z")
[https://cmake.org/cmake/help/latest/command/link\_libraries.html](https://cmake.org/cmake/help/latest/command/link_libraries.html) states that **debug|optimized|general** are keywords in **link\_libraries()**, which seems to be not the case. Our example shows this is true only for **target\_link\_libraries()**
---
### Author:  [@vvs31415](https://discourse.cmake.org/u/vvs31415)
#### Post date: [March 14, 2026, 2:48pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/6 "2026-03-14T14:48:25Z")
Note that **debug|optimized|general** are unusual for CMake because they are case sensitive.
The library names General or Optimized are fine. Maybe these keywords should have been made all-uppercase.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [March 14, 2026, 9:20pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/7 "2026-03-14T21:20:49Z")
The `debug`, `optimized` and `general` keywords are from very old CMake days. So old that most folks are not even aware they exist. They should not be used in any project today. I also recommend you don’t name a target any of those specific names, for reasons like the one you’re posting about here. All three are not good names for a target anyway, and `general` in particular is overly… general.
---
### Author:  [@vvs31415](https://discourse.cmake.org/u/vvs31415)
#### Post date: [March 14, 2026, 11:36pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/8 "2026-03-14T23:36:52Z")
Sometimes we do not have control over naming. For (real life) example, there might be a schema file **general.xsd** , then a framework must generate a library project named **general**.
---
### Author:  [@vvs31415](https://discourse.cmake.org/u/vvs31415)
#### Post date: [March 16, 2026, 1:48pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/9 "2026-03-16T13:48:37Z")
> [@craig.scott](#):
>
> They should not be used in any project today
Maybe phase them out?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 17, 2026, 5:59pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/10 "2026-03-17T17:59:27Z")
Yes, a target-policy to indicate that these indicators are not used would be useful I think.
Cc: @brad.king
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [March 17, 2026, 7:26pm UTC](https://discourse.cmake.org/t/problem-with-general-library-name/15559/11 "2026-03-17T19:26:43Z")
The `general`, `debug`, and `optimized` keywords are meaningful only in `target_link_libraries` arguments (and maybe `link_libraries`). They are still used by find modules, both upstream and in the wild, through [SelectLibraryConfigurations](https://cmake.org/cmake/help/v4.3/module/SelectLibraryConfigurations.html), in order to report `Foo_LIBRARIES` as a single result variable:
```cmake
set(Foo_LIBRARIES optimized ${Foo_LIBRARY_RELEASE} debug ${Foo_LIBRARY_DEBUG})
```
This is left from pre-imported-target style find modules where the result is expected to be used like this:
```cmake
target_link_libraries(consumer PRIVATE ${Foo_LIBRARIES})
```
In general such legacy result variables from find modules are not expected to have generator expressions in them. I don’t think we can stop supporting this use case, as it was pervasive at one time and likely has a huge legacy ecosystem.
The above-suggested `$<1:general>` is a good workaround to prevent `target_link_libraries` from treating it as a keyword.