Package multiple configs?

[alexreinking]

Currently, scikit-build-core builds a CMake project only once, in Release mode by default. It would be useful to be able to additionally package Debug binaries.

This would involve re-configuring with -DCMAKE_BUILD_TYPE=Debug in place and re-running the build for single-config generators (Ninja). For multi-config generators (e.g. Visual Studio), it would need to run cmake --build ... --config Debug. Then one would simply install to the same prefix.

Naturally this should be opt-in, perhaps by setting cmake.build-type to a list of types. It might additionally be useful to provide an option to use multiple build directories rather than reconfiguring in place when using a single-config generator. Some projects break under such circumstances.

[LecrisUT]

Would make sense for non-python wheels.

What is the install process for the libraries in this case? And how would the python library part make sure it is linked to at least one version of the library? I think this would make sense in the editable environment, but I'm not sure about the wheel install part.

[henryiii]

We should look at what py-build-cmake does, as that is supported there. Maybe this would make more sense once we have an install command?

[mortbopet]

+1 for this - ran across exactly the same problem as @alexreinking describes. As mentioned by @henryiii, py-build-cmake does provide a solution here, and i've confirmed that it works.

[LecrisUT]

From the user side, how does this look/work? I see that CMAKE_<CONFIG>_POSTFIX is supposed to be (manually?) included, but then wouldn't you need to also adjust the import statements? For development, I think editable installs would give you more freedom and put you in a more cmake native land (adding an editable mode that links directly to the build tree is on my todo). For usage outside of debugging environment I am even more curious how would the pyproject.toml look like.

[mortbopet]

@LecrisUT correct, import statements need to be adjusted as well. I personally don't think it's too bad. as explaned here, this can be hidden from the user by selecting at runtime, on module load during your __init__.py file (which most project probably already has, since this pattern of wrapping a pybound module in a python package seems to be the standard), as follows:

import os
import typing
if not typing.TYPE_CHECKING and os.getenv('PYBIND11_PROJECT_PYTHON_DEBUG'):
    from ._add_module_d import *
    from ._add_module_d import __version__
else:
    from ._add_module import *
    from ._add_module import __version__