# How to evaluate $\<CONFIG\>\_POSTFIX?

**URL:** https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984
**Category:** Usage
**Created:** [September 15, 2023, 3:08pm UTC](https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984 "2023-09-15T15:08:08Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![opoplawski](https://discourse.cmake.org/user_avatar/discourse.cmake.org/opoplawski/32/3829_2.png) [@opoplawski](https://discourse.cmake.org/u/opoplawski)
#### Post date: [September 15, 2023, 3:08pm UTC](https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984/1 "2023-09-15T15:08:08Z")

</div>

I’m trying to do:

```auto
    install ( FILES
        ${CMAKE_CURRENT_BINARY_DIR}/BTF.pc
        DESTINATION ${SUITESPARSE_LIBDIR}/pkgconfig RENAME BTF${$<CONFIG>_POSTFIX} )

```

Which doesn’t work (‘\<’ in variable name). And $\_POSTFIX evaluated to Release\_POSTFIX.  
How do I get this to evaluate to whatever the build type postfix is? Thanks!

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 15, 2023, 3:35pm UTC](https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984/2 "2023-09-15T15:35:03Z")

</div>

`install` doesn’t support genex arguments (not that this works anyways as the variable expansion will try to go before the genex is expanded). I think the best you can do is `install(SCRIPT)` where you write it with each configuration’s postfix variable as a `set()` to it and then perform the `file(INSTALL)` manually for the requested configuration. I can try to sketch some actual code later, but I don’t have time right now.

---

<div class="post-metadata">

### Author: ![opoplawski](https://discourse.cmake.org/user_avatar/discourse.cmake.org/opoplawski/32/3829_2.png) [@opoplawski](https://discourse.cmake.org/u/opoplawski)
#### Post date: [September 16, 2023, 5:04pm UTC](https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984/3 "2023-09-16T17:04:11Z")

</div>

Hmm, that seems cumbersome. Perhaps I should back up a bit and talk about the general situation:

In Fedora we build a number of BLAS using libraries in multiple flavors:

- standard
- 64-bit INTs with no symbol suffix
- 64-bit INTs with \_ symbol suffix

I’m trying to update the suitesparse package to the latest which is using cmake to build now and I need to build these multiple configurations - but I need to end up with different cmake and pkgconfig configurations for the different builds.

Does the above seem like the right direction for the pkgconfig files? For the cmake files I’m starting to try with CMAKE\_BUILD\_TYPE set to Release, Release64, Release64\_ for the different builds. Does that seem right?

I’m also trying out `RENAME '$name'${${CMAKE_BUILD_TYPE}_POSTFIX}` which seems to expand better. But apparently that does not work, resolves to empty for me.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 18, 2023, 8:29am UTC](https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984/4 "2023-09-18T08:29:21Z")

</div>

> [@opoplawski](#):
>
> I’m trying to update the suitesparse package to the latest which is using cmake to build now and I need to build these multiple configurations - but I need to end up with different cmake and pkgconfig configurations for the different builds.

Hrm. Separate prefixes like MPI does sounds easier, but I guess that ship has sailed (nevermind the cross-product problem given the likely overlap of MPI and BLAS usage).

> [@opoplawski](#):
>
> I’m also trying out `RENAME '$name'${${CMAKE_BUILD_TYPE}_POSTFIX}` which seems to expand better. But apparently that does not work, resolves to empty for me.

Try to uppercase the build type first.

I suspect that adding a `SUITESPARSE_VARIANT_SUFFIX` cache variable (or similar) to control this upstream and using it everywhere it makes sense would be better and less “oops, forgot a spot”-prone.

---

<div class="post-metadata">

### Author: ![opoplawski](https://discourse.cmake.org/user_avatar/discourse.cmake.org/opoplawski/32/3829_2.png) [@opoplawski](https://discourse.cmake.org/u/opoplawski)
#### Post date: [September 23, 2023, 2:58am UTC](https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984/5 "2023-09-23T02:58:58Z")

</div>

This seems to work:

```auto
string(TOUPPER "${CMAKE_BUILD_TYPE}" CMAKE_BUILD_TYPE_UPPER)
     install ( FILES
         ${CMAKE_CURRENT_BINARY_DIR}/BTF.pc
        DESTINATION ${SUITESPARSE_LIBDIR}/pkgconfig RENAME BTF${CMAKE_${CMAKE_BUILD_TYPE_UPPER}_POSTFIX}.pc )

```

I’m trying to find a fairly generic method that could apply to any cmake project. I’ve opened some discussion in suitespare here: [Need ability to build and package multiple configurations of suitesparse · Issue #425 · DrTimothyAldenDavis/SuiteSparse · GitHub](https://github.com/DrTimothyAldenDavis/SuiteSparse/issues/425)

Unfortunately I can’t install the different build types to the same cmake directory. I get:

```auto
-- Old export file "/home/orion/BUILDROOT/suitesparse-7.2.0-0.2.fc40.x86_64/usr/lib64/cmake/SuiteSparse_config/SuiteSparse_configTargets.cmake" will be replaced. Removing files [/home/orion/BUILDROOT/suitesparse-7.2.0-0.2.fc40.x86_64/usr/lib64/cmake/SuiteSparse_config/SuiteSparse_configTargets-release.cmake].

```

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 23, 2023, 11:40am UTC](https://discourse.cmake.org/t/how-to-evaluate-config-postfix/8984/6 "2023-09-23T11:40:51Z")

</div>

> [@opoplawski](#):
>
> Unfortunately I can’t install the different build types to the same cmake directory. I get:

You may need to `DESTDIR`-redirect them and then overlay them. Or you should use `Ninja Multi-Config` which is more multi-config aware (and would also verify that your overlapping artifacts are