# \--install . behaviour differs from --build . --target install
**URL:** https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167
**Category:** Usage
**Created:** [December 10, 2024, 4:04am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167 "2024-12-10T04:04:40Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 10, 2024, 4:04am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/1 "2024-12-10T04:04:40Z")
I configure a project via:
cmake -S …/ -B . -DCMAKE\_BUILD\_TYPE=None -DCMAKE\_INSTALL\_PREFIX=/tmp/prefix -G ‘Unix Makefiles’
In CMakeLists,txt there is call to install(export):
install(EXPORT ${PROJECT\_NAME}Targets
NAMESPACE pkg::
DESTINATION “${CMAKE\_INSTALL\_LIBDIR}/cmake/${PROJECT\_NAME}”
)
Now when I build/install via:
cmake --build . --config Release --target install
(note the redundant --config which should be ignored because of single file generator)
I see 2 files:
pkgTargets.cmake pkgTargets-none.cmake
The 2nd file corresponds to the CMAKE\_BUILD\_TYPE I used to configure.
Now if I clean everything and try the same with:
cmake --build . --config Release
cmake --install . --config Release
I only see:
pkgTargets.cmake
There -none.cmake file has not been created?
I also tested without the redundant --config Release and it works as expected eg
cmake build .
cmake install .
And tested with --config None and this also works as expected.
cmake --build . --config None
cmake --install . --config None
I would actually expect both of these --config options to be ignored?
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [December 10, 2024, 5:46am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/2 "2024-12-10T05:46:59Z")
> [@matt-sm](#):
>
> DCMAKE\_BUILD\_TYPE=None
Why do you set an invalid build type?
---
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 10, 2024, 5:54am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/3 "2024-12-10T05:54:25Z")
What makes you think None is an invalid build type?
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [December 10, 2024, 6:22am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/4 "2024-12-10T06:22:18Z")
The default supported [build types](https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html) are:
```auto
bash-5.2$ cmake -LA . | egrep '(CXX_FLAGS|BUILD_TYPE)'
CMAKE_BUILD_TYPE:STRING=
CMAKE_CXX_FLAGS:STRING=
CMAKE_CXX_FLAGS_DEBUG:STRING=-g
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
bash-5.2$
```
---
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 10, 2024, 6:38am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/5 "2024-12-10T06:38:55Z")
Is that command contextual? When I run in my build folder:
```auto
cmake -LA . | egrep '(CXX_FLAGS|BUILD_TYPE)'
Generated with config types:
Generated with build type: None
CMAKE_BUILD_TYPE:STRING=None
CMAKE_CXX_FLAGS:STRING=
CMAKE_CXX_FLAGS_DEBUG:STRING=-g
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_CXX_FLAGS_NONE:STRING=
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
```
Which is the reason I am using None.
I don’t want any of the flags appended that these other build types include.
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [December 10, 2024, 7:05am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/6 "2024-12-10T07:05:11Z")
Quote from docs:
> The default value is often an empty string, but this is usually not desirable and one of the other standard build types is usually more appropriate.
> I don’t want any of the flags appended that these other build types include.
You may use `-D CMAKE_CONFIGURATION_TYPES=None`
---
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 10, 2024, 7:50am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/7 "2024-12-10T07:50:35Z")
> You may use `-D CMAKE_CONFIGURATION_TYPES=None`
> Interesting - I will test that
For a single config generator, I thought setting configuration was “ignored”
Have you ever seen: [https://wiki.archlinux.org/title/CMake\_package\_guidelines](https://wiki.archlinux.org/title/CMake_package_guidelines)
This is where I got the inspiration for CMAKE\_BUILD\_TYPES=None
---
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 10, 2024, 8:37am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/8 "2024-12-10T08:37:28Z")
with -D CMAKE\_CONFIGURATION\_TYPES=None none of the erroneous flags are added to the compile commands which looks promising, and if I do
cmake --install .
I get a pkgTargets-noconfig.cmake which looks correct
But if I specify any value for --config eg.
cmake --install . --config None
or
cmake --install . --config Release
the -noconfig file is not generated, similar to the previous observation
---
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 10, 2024, 8:48am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/9 "2024-12-10T08:48:16Z")
In this particular instance there is no difference in setting -D CMAKE\_CONFIGURATION\_TYPES=None or just not setting it at all
Both you end up with a noconfig export file
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [December 10, 2024, 9:29am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/10 "2024-12-10T09:29:25Z")
- which cmake version are you using?
- on which OS?
- try same with `Ninja` generator please
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [December 10, 2024, 8:07pm UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/11 "2024-12-10T20:07:06Z")
Setting `CMAKE_BUILD_TYPE` to `None` is incorrect. You are saying you want to use a custom build type that is literally called `None`. Since you define no variables for this custom `None` build type, it may coincidentally behave similar to `CMAKE_BUILD_TYPE` being unset or set to an empty string, but there may be corner cases where that isn’t so. The output you showed earlier with this value `None` is really just trying to tell you that `CMAKE_BUILD_TYPE` holds an empty string.
Setting `CMAKE_CONFIGURATION_TYPES` for a single config generator should be meaningless, don’t do it.
If you truly want the effect of getting `CMAKE_CXX_FLAGS` but none of the other `CMAKE_CXX_FLAGS_` flags, then setting `CMAKE_BUILD_TYPE` to an empty string would achieve that. But as the docs say, that is almost never what a developer wants. I would question the use case where you don’t want any configuration, but you haven’t given any detail why you want that specific behavior. If you were using a multi-config generator, you don’t have the choice of an empty configuration. Being able to use one for single configuration generators is a bit of an anomaly.
---
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 10, 2024, 10:22pm UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/12 "2024-12-10T22:22:52Z")
We build many 3rd party dependencies that already have cmake builds, but we use bazel with a [bazel cmake wrapper](https://github.com/bazel-contrib/rules_foreign_cc). We have also defined our own custom bazel gcc toolchain, and we would prefer that to be the source of truth for for our optimisation flags, rather than cmake adding in it’s own defaults depending on what CMAKE\_BUILD\_TYPE is set to.
And yes, the upstream projects themselves may have logic on CMAKE\_BUILD\_TYPE as well, but many don’t, but we could patch this logic out.
That is why I was looking to see what the arch project does, and a colleague also linked the gentoo project and their cmake wrapper.
So until now we’ve just been setting CMAKE\_BUILD\_TYPE to None and this has for the most part worked, but I am open to better guidance on how to handle this requirement.
cmake version 3.22.1
Ubuntu 22.04.5 LTS
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [December 11, 2024, 9:38pm UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/13 "2024-12-11T21:38:28Z")
The clearest approach to what you are trying to achieve would probably be to define your own custom config. Give it a name that makes clear what the custom config represents, don’t use `None`. If you don’t define the config-specific variables `CMAKE_CXX_FLAGS_`, they default to empty, and that sounds like what you’re wanting. This will be essentially the same as using `None` like you are now, but without the confusion and potential corner cases where `None` might be taken to mean something special (I don’t recall where I’ve seen that, better just to avoid the problem by using a better name).
One down side of using a custom config though is when you install your project, you’re installing that config, not Debug or Release. If consumers are making assumptions about what configurations a target is provided in, they may have trouble dealing with your custom configuration.
An alternative would be to overwrite flag variables like `CMAKE_CXX_FLAGS_RELEASE`, discarding the default contents and setting them to whatever flags want to enforce. But some projects then modify that value, which projects shouldn’t do, but it is unfortunately still common. Even then, projects can also add flags in other (legitimate) ways, so you may have a hard time truly enforcing a consistent set of flags across all projects.
---
### Author:  [@matt-sm](https://discourse.cmake.org/u/matt-sm)
#### Post date: [December 12, 2024, 6:04am UTC](https://discourse.cmake.org/t/install-behaviour-differs-from-build-target-install/13167/14 "2024-12-12T06:04:29Z")
Craig, thanks so much for responding with ideas on different approaches.
> One down side of using a custom config though is when you install your project, you’re installing that config
This seems related to my observation: Building with `CMAKE_BUILD_TYPE=None` and installing with `--config Release` resulted in no `MyLibraryTargets-.cmake` file being generated.
> If consumers are making assumptions about what configurations a target is provided in, they may have trouble dealing with your custom configuration
I assume you mean the assumptions the library authors themselves make within their custom CMake. We can limit this somewhat by controlling the build/install types/configs on both sides, but yes its another potential source of errors.