Build both release and debug for Windows

[maxhora]

No description provided.

[jakirkham]

So if we were to do it on Windows, we should probably do it on Unix. Also we would need a build number bump.

[jakirkham]

That all said, what is your interest in having debug builds of Boost? Why it would be a good idea to have them included in a large stack like conda-forge? What possible issues could it cause?

[isuruf]

I think windows is special, in that if you want a debug build of your library, you need to have debug libraries of all your dependencies.

[maxhora]

I'm trying to build Arrow https://github.com/apache/arrow statically on Windows in Debug. Conda-forge provides only release static build of boost, but it's not compatible with debug static builds by MSVC toolchain (different runtimes are used).

[jakirkham]

Right. So this is not the first time debug builds have come up on Windows. Most notably this has been discussed with Python. However, I think we need to come to some consensus about how this should look for the stack as opposed to adding it piecemeal to packages of interest. While the latter is expedient, it is almost certainly going to end in breakage if we don't have some consensus about how this is done. I would propose that a few interested people put together a CFEP that lays out the right way to do debug builds and how they are enabled. I think that will make it easier to see what works best and will serve conda-forge best.

cc @tadeu @wesm @dfroger @conda-forge/core

xref: conda-forge/python-feedstock#73
ref: https://github.com/conda-forge/conda-forge-enhancement-proposals

[maxhora]

Thanks! For example, here it's screenshot of AppVeyor's boost installation. By default, they provides both debug, release and static, shared libs of boost.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[wesm]

@jakirkham my understanding is that Boost is designed to be able to build both release and debug builds on Windows (https://theboostcpplibraries.com/introduction-installation), so at least in this special case I don't believe there is necessarily a conflict

In general, for libraries that need to statically link symbols, it would be useful to be able to use pre-built libraries from conda-forge where possible during development.

[tadeu]

Note that there are three different "flags" that control different aspects of "debug" in Boost (source):

  g     using debug versions of the standard and runtime support libraries. 
        (runtime-debugging=on)
  y     using a special debug build of Python.
        (python-debugging=on)
  d     building a debug version of your code.
        (variant=debug)

In practice, either gyd or gd would make sense. gyd would need this "special debug build of Python" (aka pydebug or python_d, built using the flag --with-pydebug). pydebug changes the layout of PyObjects, making it necessary for all extensions to be built with this support, so it's the most difficult to support.

gd only uses the debug runtime (CRT). In theory, libraries that use the debug runtime can be mixed with libraries that use the release runtime, as long as they are very well isolated (i.e., no allocation done in one side and deallocation in the other side, the same for other resources such as file handles), otherwise it risks presenting crashes such as heap corruption.

I think that if gd works for Boost, i.e., if it can be mixed with other packages in release (as long as those packages do not depend on Boost itself), then it is a good candidate for the gradual introduction of debug packages in conda-forge.

[tadeu]

@Maxris I don't know if it should all be in the same package: it will more than double the package size, and most people won't ever use the debug libraries. Plus, there are some libraries such as VTK that have the same filename for both the release and the debug version of some shared libraries.

Perhaps a different package that depends on the debug feature would work better here (it could be done using the same recipe, but a different job in the matrix, controlled by an environment variable, for example).

[jschueller]

I agree with tadeu.

[jakirkham]

FWIW this is still a great idea that we should really revive it (especially as the tooling has caught up a bit). Raised issue ( conda-forge/conda-forge.github.io#544 ) to discuss how we do split packages and generate things like debug builds as products.