Debug builds

[johne53]

I'm finding vcpkg pretty useful but there's one thing niggling me...

Packages tend to build both a Release target and a Debug target but AFAICT for the majority of packages, the built names are identical for both targets. For example the built DLLs for glib are both called glib-2.0.0.dll. And in some cases, Debug DLL and Release DLL have identical sizes - so it can only be a matter of time here before someone gets them mixed up.

I prefer to use the old Microsoft format whereby Debug builds had a letter 'D' added at the end - i.e. for glib, the Debug DLL would be called glib-2.0.0D.dll.

Is there some way I can achieve that locally? And of so, where/what would I need to edit?

[Osyotr]

Vcpkg usually does not rename output file names. If the upstream produces the same file name for both debug and release builds, vcpkg does not attempt to patch that out.
Equal file names is usually not a problem unless the package does not provide CMake config and you need multi-config support (in that case there's no "clean" way to find library file for the corresponding config).

I prefer to use the old Microsoft format whereby Debug builds had a letter 'D' added at the end - i.e. for glib, the Debug DLL would be called glib-2.0.0D.dll.

If glib built from unmodified sources has D in the file name for debug build and glib from vcpkg does not, then this is a bug in vcpkg.

[dg0yt]

There is no easy way to do it. Things are integrated, and integration is tested, as is, with debug binaries stored to a different path.

In the broad spectrum of ports in vcpkg, even installing different names would (and did) lead to mixup because it is tricky to lookup different names in correct order for names and paths. Many upstreams are not prepared for it.

Apart from preference, is there any actual problem?

[johne53]

Yes I can see the problem. For example, glib is dependent on other packages, such as libintl and gettext, so they'd need to get changed too. What would be nice would be if vcpkg install came with some command-line option to just do this automatically for Debug builds but I guess that'd be difficult too?

So far, there haven't been any issues here with the current naming but I can well imagine it causing problems at some point and they'd be very difficult to track down :-(

[Neumann-A]

but I guess that'd be difficult too?

The problem is there is no support for it in the packages.

I can well imagine it causing problems at some point and they'd be very difficult to track down

Dont try to copy release/debug into the same folder? As long as you keep them cleanly separated there shouldn't be an issue.
You can always track the link line to see if the correct library has been linked. Debug versions need to contain /debug/ in their path.

[johne53]

I suppose this raises an obvious question:- i.e. does vcpkg utilise each library's build system directly, or does it simple emulate it? Taking glib as an example, I'm pretty sure that it's build system (on Windows) is all based around MSVC project files (.vcxproj)

So if those files were being used directly, it'd be quite simple to edit them. OTOH if their actions are being emulated, that makes it more difficult (and other packages won't even be using .vcxproj file of course).

[dg0yt]

vcpkg prefers upstream's buildsystems, and if upstream supports more than one, we prefer a single cross platform build over 255 different per-platform builds.

I believe you didn't really look at the ports. And you probably didn't really see the effort of scaling and maintaining "quite simple to edit".

[Neumann-A]

I'm pretty sure that it's build system (on Windows) is all based around MSVC project files (.vcxproj)

i am pretty sure it is not. looks more like meson.build to me. vcpkg does not "emulate", vcpkg tries to invoke upstream as intended.

[johne53]

I just looked at our build of glib here (version 2.54.3) and there are loads of MSVC projects - though to be fair, they're the older .vcproj files - so yes, maybe this all got changed in the more recent versions..