This sounds like a reasonable feature request. Please file an issue at https://github.com/grpc/grpc, so the request does not get lost.
FYI, CMake is not a top priority for the maintenance team at the moment, and we are a bit short-staffed, so this may require a community contribution to get it implemented. Best, Adam On Thursday, July 10, 2025 at 12:14:48 PM UTC-7 Randy Ward wrote: > It does when I'm not importing the CMAKE library target. > I think this is a more complicated issue because of grpc's dependencies. > Specifically UTF8 and ABSL. > I've been able to hard-code a workaround for this, but it involves manual > editing of files and I would love it if someone wanted to make a request > for the dependent libraries to properly support multiple-configuration > INSTALL targets. > > Specifically, let's look at UTF8 as an example since it's very simple. > > UTF8 generates a lib/cmake/utf8_range/utf8_range-targets-debug.cmake OR a > lib/cmake/utf8_range/utf8_range-targets-release.cmake file, depending on > the configuration. > > GREAT so far. > > The top level utf8-range-targets.cmake file includes both of them for > possible configuration UTF8 generates lib/utf8_range.lib and > lib/utf8_validity.lib as output files. > > The problem is that if you build Release or Debug the same files get > generated as an INSTALL target. > So whichever you build last is the one that is copied to the install > directory. "utf8_range.lib" could be either debug or release. > > One solution would be to append a "d" to the filename to denote which > files are for the debug configuration. Protobuf does this (but not > protobuf's dependent libraries!). > > If you renamed the files based on the debug/release configuration, the > result would be a lib/utf8_range.lib and lib/utf8_ranged.lib > > Then all you'd have to do is modify the lib/utf8_range-targets-debug.cmake > file to point to the lib files with the debug suffix in the filename. Then > you can switch between the debug and release libraries using the same > INSTALL directory. Both debug and release libraries would sit side by side > in the same folder. > > I've been able to make the dependencies work this way, but it is an > absolute pain doing it by hand because of all of the "target" libraries in > absl and utf8. > > On Tuesday, July 8, 2025 at 5:48:56 PM UTC-4 [email protected] wrote: > >> Hey Randy, >> >> If you use cmake when building gRPC, it might be working if you build >> like "cmake --build . --config Release" without regenerating it. >> >> Regards, >> Esun. >> >> On Monday, June 30, 2025 at 8:48:56 AM UTC-7 Randy Ward wrote: >> >>> Is there any install target that builds debug and release static >>> libraries side by side? For instance, my use case would be to build grpc >>> and then use cmake's $<CONFIG> parameter to select release or debug with >>> grpc as an IMPORTED CMake target. >>> >>> It looks like grpc builds the debug and release libraries with the same >>> name. Instead of seeing grpc.lib and grpc_d.lib, they're both named >>> grpc.lib. This means they can not coexist for the same install target >>> through CMAKE. >>> >>> A quick example of this problem is to do the following actions (I'm >>> using v1.72, but this should still be recent enough): >>> >>> 1) Checkout the git module and submodules for grpc. >>> 2) navigate to the test\distrib\cpp directory >>> 3) Run the run_distrib_test_cmake.bat batch file (noting that you'll >>> need powershell and other things in your path for it to complete >>> successfully). >>> 4) Navigate to the examples\cpp\helloworld\cmake\build directory and >>> open the HelloWorld.sln that is built by the batch file above. VS 2022 (in >>> my case) will open the project. >>> 5) Attempt to build using the default Debug target. It will fail. >>> This is because grpc was built using Release above, and not debug. You >>> will get an output similar to the following: >>> >>> 7>grpc++.lib(completion_queue_cc.obj) : error LNK2038: mismatch detected >>> for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in >>> greeter_async_server.obj >>> 7>grpc++.lib(completion_queue_cc.obj) : error LNK2038: mismatch detected >>> for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value >>> 'MDd_DynamicDebug' in greeter_async_server.obj >>> 7>grpc++.lib(insecure_server_credentials.obj) : error LNK2038: mismatch >>> detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in >>> greeter_async_server.obj >>> 7>grpc++.lib(insecure_server_credentials.obj) : error LNK2038: mismatch >>> detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match >>> value 'MDd_DynamicDebug' in greeter_async_server.obj >>> 7>grpc++.lib(server_context.obj) : error LNK2038: mismatch detected for >>> '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in >>> greeter_async_server.obj >>> 7>grpc++.lib(server_context.obj) : error LNK2038: mismatch detected for >>> 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value >>> 'MDd_DynamicDebug' in greeter_async_server.obj >>> >>> --- >>> >>> Now, I understand that this is looking for Debug windows symbols that >>> aren't in the generated Release library. >>> >>> I understand that the way to solve this is to build the library for >>> Debug and not Release. >>> >>> The question I have, is: Is there a way to build both debug and release >>> versions of the GRPC (and dependencies) libraries such that I can switch >>> between Debug and Release configurations of a build without having to call >>> CMake again to change the location of find_package(grpc CONFIG REQUIRED)? >>> I saw a note about changing the CMakePresets.json file, and this would work >>> to switch between two install directories of GRPC, but I want to avoid >>> having to do this if at all possible, as it appears to be a workaround and >>> calls CMake to configure for each build designation instead of simply using >>> a common CMake target and switching between a CONFIG target. >>> >>> I apologise for the dense CMake terminology. Perhaps there is a simpler >>> way to build the debug targets with different library names. If anybody >>> can point me in that direction, that would be great. >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/grpc-io/dc3d709e-5dda-43fa-8330-ce653dc0ebe0n%40googlegroups.com.
