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/11c89057-00fc-4a0b-9949-2c607c7d75fdn%40googlegroups.com.
