Can't build a project that contain only ``library()``

[moi15moi]

Problem 1
When building my wheel on windows, I get this error:

[1/2] D:\a\test_meson\test_meson\.mesonpy-v0dib87v\example.dll
[2/2] D:\a\test_meson\test_meson\.mesonpy-v0dib87v\example.lib
Traceback (most recent call last):
  File "C:\hostedtoolcache\windows\Python\3.13.12\x64\Lib\site-packages\pyproject_hooks\_in_process\_in_process.py", line 389, in <module>
    main()
    ~~~~^^
  File "C:\hostedtoolcache\windows\Python\3.13.12\x64\Lib\site-packages\pyproject_hooks\_in_process\_in_process.py", line 373, in main
    json_out["return_val"] = hook(**hook_input["kwargs"])
                             ~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\hostedtoolcache\windows\Python\3.13.12\x64\Lib\site-packages\pyproject_hooks\_in_process\_in_process.py", line 280, in build_wheel
    return _build_backend().build_wheel(
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        wheel_directory, config_settings, metadata_directory
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "C:\Users\runneradmin\AppData\Local\Temp\build-env-03i4_as2\Lib\site-packages\mesonpy\__init__.py", line 1203, in wrapper
    return func(*args, **kwargs)
  File "C:\Users\runneradmin\AppData\Local\Temp\build-env-03i4_as2\Lib\site-packages\mesonpy\__init__.py", line 1257, in build_wheel
    return project.wheel(out).name
           ~~~~~~~~~~~~~^^^^^
  File "C:\Users\runneradmin\AppData\Local\Temp\build-env-03i4_as2\Lib\site-packages\mesonpy\__init__.py", line 1100, in wheel
    return builder.build(directory)
           ~~~~~~~~~~~~~^^^^^^^^^^^
  File "C:\Users\runneradmin\AppData\Local\Temp\build-env-03i4_as2\Lib\site-packages\mesonpy\__init__.py", line 511, in build
    self._install_path(whl, src, dst)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
  File "C:\Users\runneradmin\AppData\Local\Temp\build-env-03i4_as2\Lib\site-packages\mesonpy\__init__.py", line 465, in _install_path
    wheel_file.write(origin, destination.as_posix())
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\runneradmin\AppData\Local\Temp\build-env-03i4_as2\Lib\site-packages\mesonpy\_wheelfile.py", line 97, in write
    with open(filename, 'rb') as f:
         ~~~~^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'D:\\a\\test_meson\\test_meson\\.mesonpy-v0dib87v\\example.lib'
ERROR Backend subprocess exited when trying to invoke build_wheel

Problem 2
On platform where I can build the wheel without issue, even thought I don't use python extension, the wheel is named like this: example-1.0.0-cp313-cp313-linux_x86_64.whl, example-1.0.0-cp313-cp313-macosx_15_0_arm64.whl.
I would have expected to be example-1.0.0-py3-none-linux_x86_64.whl, example-1.0.0-py3-none-macosx_15_0_arm64.whl.

How to reproduce
You can get the project here: https://github.com/moi15moi/test_meson
It is a really simple project. The meson.build just contain a library().

Note that you can see how I builded the wheel in the workflow: https://github.com/moi15moi/test_meson/actions/runs/24110794731
On unix, I used the command python -m build --wheel and on windows, I used the command python -m build --wheel -Csetup-args="--vsenv".

[dnicolodi]

Problem 1 When building my wheel on windows, I get this error:

[1/2] D:\a\test_meson\test_meson.mesonpy-v0dib87v\example.dll
[2/2] D:\a\test_meson\test_meson.mesonpy-v0dib87v\example.lib
[...]
FileNotFoundError: [Errno 2] No such file or directory: 'D:\a\test_meson\test_meson\.mesonpy-v0dib87v\example.lib'
ERROR Backend subprocess exited when trying to invoke build_wheel

This looks like a bug in Meson: the introspection data says that an import library is generated, but there isn't one. There definitely is one when compiling with GCC or Clang (the meson-python test suite contains several instances of this, but lcearly we don't run the tests with MSVC). It seems that there isn't one when compiling with MSVC. I don't know if this is a bug in the generated ninja rules or if I am missing something.

Problem 2 On platform where I can build the wheel without issue, even thought I don't use python extension, the wheel is named like this: example-1.0.0-cp313-cp313-linux_x86_64.whl, example-1.0.0-cp313-cp313-macosx_15_0_arm64.whl. I would have expected to be example-1.0.0-py3-none-linux_x86_64.whl, example-1.0.0-py3-none-macosx_15_0_arm64.whl.

This is a known limitation of meson-python. From the Meson project only, meson-python cannot know if a binary object installed into the wheel is a Python extension (or otherwise links to the Python runtime) or not. Therefore, we err on the side of safety and we assume it does (and this is what the user intends the vast majority of times). There is not currently a mechanism to instruct meson-python to change this assumption.

[moi15moi]

This looks like a bug in Meson: the introspection data says that an import library is generated, but there isn't one.

As a side note, it doesnt happen with editable install.

This is a known limitation of meson-python.

Is it documented? I dont see it on the website.

[dnicolodi]

This is a known limitation of meson-python.

Is it documented? I dont see it on the website.

The documentation does not say that the opposite is true, or that it exists a way to influence how the wheel tags are derived. Thus, while it may be not a very far fetched expectation that this works, the documentation does not imply in any way that this works. It is far more practical to list what something does rather than what it does not do.

[rgommers]

We should fix that though. Having to manually rename wheels before shipping them is too hacky. Let's keep this issue for the bug when building with MSVC - I'll open a new issue with some suggestions for how we could address this.

[rgommers]

Actually, that's the same as gh-639.

[moi15moi]

For the Problem 1, to fix the issue, I needed to use dllexport/dllimport.

#if defined(_WIN32) && !defined(API_STATIC)
#	if defined(API_EXPORTS)
#		define API(ret) __declspec(dllexport) ret
#	else
#		define API(ret) __declspec(dllimport) ret
#	endif
#else
#	define API(ret) ret
#endif


API(char*) get_hello_world()
{
    return "Hello World!";
}

I guess meson assume we export the symbol.

[rgommers]

Ah, that makes sense. Probably can't be considered a bug then, or a very minor one at best? Shipping a library that doesn't export any symbols seems not so useful. It'd be nice if there were a clearer error message I guess.

[eli-schwartz]

The problem here if I recall correctly is that meson presumes that building a shared library is, well, a shared library. And the MSVC tools operate by telling them to produce a .dll file, so that's what ninja "knows", but the implib is produced as a side effect of compilation and the MSVC tools only do so if there happen to be actual symbols exported. Despite the fact that with no symbols the resulting dll makes no sense and is clearly a logic error, the MSVC tools don't exit with a nonzero status code and provide no real way for ninja to detect that an erroneous state was encountered.