Prevent MinGW generator from building "liblib" outputs

Environment is Windows. I’ve got an existing project that was modified from Makefiles to CMake. It builds a shared DLL library and a binary that uses it. The previous developer had MS Visual C present, and so the default behavior of CMake under Windows was fine. As near as I can tell, it build a “libX.dll” file because “libX” is added as a SHARED library in CMakeLists.txt, and “X.exe” because “X” is added as an executable.

I don’t have Visual C; I prefer MinGW (free, no license), and I can get the project to build with the -G “MinGW Makefiles” generator. However, it appears from looking at the makefiles the generator creates that the default behavior is to prepend “lib” to the shared library target. So it creates a “liblibX.dll” file.

This is undesired behavior. I’d like MinGW to produce the same filenames that Visual C does (even though the internal contents may be somewhat different).

Furthermore, I’d like to preserve the process for Visual C. I’ll bet there’s a way to conditionally switch “add_executable” and “add_library” based on a symbol created by the generator. But then I run into another problem, which is I can’t have “X” as the target for both the executable and the library, even though the library is going to end up prepending “lib” and appending “.dll” to the ultimate target.

Is there a way to (conditionally) modify the defaults of the MinGW generator to not prepend “lib” to a shared library?

Have a look at OUTPUT_NAME target property…

Good, this works. By specifying the OUTPUT_NAME as a target property, regardless of the build system, I get “libX.dll”.
Interesting (annoying?) that the generator still prepends “lib” and appends “.dll”. I started out thinking I could specify exactly the filename I wanted, “libX.dll”. But the generator gave me “liblibX.dll.dll”. I have to set the OUTPUT_NAME to “X” to get “libX.dll”.

The PREFIX and SUFFIX target properties control the lib and .dll parts respectively. I would advise you not to mess with those though, by default they will be set to follow strong platform/toolchain conventions.