-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Hi,
You were against using vcpkg for dependencies - for understandable reasons. We were working on building all dependencies for CI using vcpkg, so all the dependencies are tested during development. I don't love vcpkg, and duplicating efforts seems silly. So it seems using this repo for dependencies is the better option.
There's two problems with that as-is:
- Currently (nearly?) everything is built without debug info. Not sure if that's intentional or just happened to be that way. That seems suboptimal even from a production-workload POV, crashes and profiling need symbols.
- For CI most dependencies ought to be built linking against the debug C runtime (that detects many more bugs and it's theoretically UB to use mismatching runtimes). That's not the right thing for production builds.
The first is reasonably easy to address. For the cmake based stuff it would just be to use the RelWithDebInfo configuration instead of Release. Do you see any reason not to do so?
The second is a bit harder. One way would be to install the debug tools into their own prefix, for each of the generated archives. Then the choice of using prod/debug builds of libraries would be just about the path used in postgres build recipes?
Alternatively we could try to install them into the same path. Many windows native things name their debug libraries differently than the production ones (often <depname>d.{lib,dll}). But last time I looked that wasn't universally the case.
Greetings,
Andres