search

dpage / winpgbuild

A repo containing Github actions for building PostgreSQL and it's dependencies on Windows
1 stars 2 forks source link

Debug info and debug builds #10

Open anarazel opened 4 months ago

anarazel commented 4 months ago

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:

1) 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. 2) 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

davecramer commented 4 months ago

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.

I for one certainly think using a single repo to do this is the better option

Alternatively we could make with-debug an option if someone were using this as a github action.

I don't have a lot of experience with how windows names debug artifacts, but ISTM that putting them in their own prefix would seem easier.

Dave

dpage commented 4 months ago

I also favour using a separate prefix for the debug builds. That makes it far easier for anyone who wants to use any of the archives generated here as the basis for a package or distribution to pull out only the non-debug parts that they want to ship.

I have no objection at all to adding debug info/builds to the project - I think that's a perfectly sensible evolution.

anarazel commented 4 months ago

I also favour using a separate prefix for the debug builds.

Cool. Shouldn't be too hard to add.

I have no objection at all to adding debug info/builds to the project - I think that's a perfectly sensible evolution.

That includes including debug info for the release builds (e.g. the cmake --config Release to RelWithDebInfo)?

dpage commented 4 months ago

That includes including debug info for the release builds (e.g. the cmake --config Release to RelWithDebInfo)?

Yes.