FetchContent: how to set the URL depending the configuration ?

Hello,

I use FetchContent to retrieve binary libraries. But as I am on Window, I have to retrieve different binaries depending the configuration (Debug, Release…), so that the clients can link to any of these configurations.

I tried to add $<CONFIG> in the URL, but FetchContent_Declare() is called during the the configuration step, and so $<CONFIG> is not evaluable yet.

I tried to pass a variable on the command line when calling CMake :

cmake -G "Visual Studio 15 2017" -A x64 -D MODE=Debug ..
cmake -G "Visual Studio 15 2017" -A x64 -D MODE=RelWithDebInfo ..

But no matter the order of these calls, the latter remplaces always the files got from the former.

How could I satisfy me need ?

Maybe I should operate when creating the package…

Thanks.

In short: you can’t do this. You don’t always know the build type (Debug, Release, etc.) at CMake configure time. When using multi-configuration generators like Visual Studio, Xcode, and Ninja Multi-Config, the decision of what build type to use is made by the developer at build time, long after FetchContent has finished doing its thing.

Ideally, the package you are wanting to use would provide both Debug and Release libraries in the one build. It should inherently do this if it is being built as part of your main project like how dependencies brought in via FetchContent normally work. If the thing you’re bringing in via FetchContent contains binary packages instead of source to be built, then you do really need the binary package to provide both Debug and Release to support multi-config generators.

Thanks for confirming clearly and firmly what I finally concluded myself (by the way, the official CMake documentation is very laconic about the two steps, configuration and building ; fortunately, there is your Chapter 11 to explain that).

For now, my clients (fortunately, my company is its own client) will have to do boths commands given in my original post, according their needs, and rebuild the configuration. Because today, our IC pipeline builds and delivers to Nexus Debug or Release. It hasn’t be done to deliver both build types in a same deliverable.