1. Most CMake files only produce one configuration at a time. If you run something like

E:\git\enet>cmake -B build/ -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
-- Configuring done (0.0s)
-- Generating done (0.1s)
-- Build files have been written to: E:/git/enet/build

E:\git\enet>cmake --build build/ --config Release
MSBuild version 17.9.8+b34f75857 for .NET Framework

  1>Checking Build System
  Building Custom Rule E:/git/enet/CMakeLists.txt
  callbacks.c
  compress.c
  host.c
  list.c
  packet.c
  peer.c
  protocol.c
  unix.c
  win32.c
  Generating Code...
E:\git\enet\win32.c(94,17): warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings [E:\git\enet\build\enet.vcxproj]
E:\git\enet\win32.c(128,17): warning C4996: 'gethostbyaddr': Use getnameinfo() or GetNameInfoW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings [E:\git\enet\build\enet.vcxproj]
  enet.vcxproj -> E:\git\enet\build\Release\enet.lib
  Building Custom Rule E:/git/enet/CMakeLists.txt

you should get a static library.

Make sure to actual set BUILD_SHARED_LIBS=OFF when you have previously set it to ON.

2. This is correct, but this wasn't the case before the recent changes either.

Yes, as an OpenBSD port / package developer and having converted what probably now amounts to a couple hundred over to using CMake I noticed this is one area CMake has gotten wrong in general. Where as this isn't an issue with autoconf/libtool or Meson. Some projects have fixed this to typically have two knobs for shared and static, but that's pretty rare.

Some projects have fixed this to typically have two knobs for shared and static, but that's pretty rare.

And it makes CMake files more complicated. I would not recommend this for enet currently. Does it make your setup that much more complicated to first build one thing, then the other?

@brad0 Could you perhaps review #233 regarding pkg-config support?

@brad0 Could you perhaps review #233 regarding pkg-config support?

Sure, I'll take a look.

Applying #233 and #250 gets us close enough that I have submitted a diff updating us to .18, including the commited CMake patches + those PRs and converted over to using CMake.