PDB files shipped with Boost/MSVC releases from sourceforge trigger ERROR when using dependency('boost')

[andrzejc]

Binary Boost releaases downloaded from https://sourceforge.net/projects/boost/files/boost-binaries/ include debbuging information in separete .pdb files stored alongside .lib and .dll files in lib<32|64>-msvc-<version> directories.

The error visible in the log looks like this:

meson.build:13:0: ERROR: Unable to process library extension "pdb" (C:\opt\moonlight-deps\boost_1_75_0\lib32-msvc-14.1\boost_atomic-vc141-mt-gd-x32-1_75.pdb)

which hints at the following code location:

meson/mesonbuild/dependencies/boost.py

Line 155 in 2a8d669

raise DependencyException('Unable to process library extension "{}" ({})'.format(self.nvsuffix, self.path))

I think the official binary releases for MSVC should be consumable in the form they are shipped.
Workaround: currently I need to move .pdb files to separate directory, which requires write access to the lib... directory - not always available on CI systems with boost preinstalled.

[nanthony21]

I'm running into this same issue.

[nanthony21]

Maybe the cleanest solution is to add a case here to exclude certain file suffixes?

meson/mesonbuild/dependencies/boost.py

Line 620 in 2a8d669

if not i.is_file() or i.is_symlink():

Or maybe the BoostLibraryFile class should have a static is_file_valid(fileName: Path) -> bool: method which is used to ignore unsupported files?

[intractabilis]

I have the same issue. What really should happen is Meson should start using the official way of detecting boost libraries, i.e. via CMake. See #8801.

[insunaa]

I have the same issue. What really should happen is Meson should start using the official way of detecting boost libraries, i.e. via CMake. See #8801.

Forgive my ignorance: I use meson specifically so I can avoid the need for CMake. What is the point of Meson if it only calls CMake in the end, anyway?

Edit: I'm not saying that it must avoid CMake at all costs, I think having CMake as a fallback for finding dependencies is helpful. But why should CMake be a required dependency of Meson? If I have to use some buildsystem anyway and Meson requires CMake+Ninja, while CMake requires only autotools... why not use CMake at that point? Meson doesn't do anything particularly special to distinguish itself from CMake, aside from having a shorter syntax. Some projects I work on even build slower with Meson compared to CMake.

[intractabilis]

Forgive my ignorance: I use meson specifically so I can avoid the need for CMake. What is the point of Meson if it only calls CMake in the end, anyway?

Not all third-party libraries support Meson. If authors of library X use CMake, Meson must use CMake to know how to find and compile library X with your code.

[eli-schwartz]

Meson doesn't "must" any such thing, because as we see it can do this with just python, therefore we have a happy case where it turns out cmake is not needed. ;)

[intractabilis]

Meson doesn't "must" any such thing, because as we see it can do this with just python, therefore we have a happy case where it turns out cmake is not needed. ;)

Reimplementing CMake in Python is a non-starter. Meson must, and it does call CMake behind the scene for other libraries. Regarding boost in particular, the way Meson stubbornly refuses the officially supported way to find boost libraries causes maintenance problems, does have bugs, and will have more bugs in the future.

[mensinda]

You are free to try to implement it using CMake and submit a PR. However, be warned that I **did** try implementing this way and it turned out tob be even more buggy and unmaintainable.

On 10 May 2022 06:26:37 CEST, intractabilis ***@***.***> wrote: > Meson doesn't "must" any such thing, because as we see it can do this with just python, therefore we have a happy case where it turns out cmake is not needed. ;) Reimplementing CMake in Python is a non-starter. Meson must, and it does call CMake behind the scene for other libraries. Regarding boost in particular, the way Meson stubbornly refuses the officially supported way to find boost libraries causes maintenance problems, does have bugs, and will have more bugs in the future. -- Reply to this email directly or view it on GitHub: #8325 (comment) You are receiving this because you modified the open/close state. Message ID: ***@***.***>

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[intractabilis]

However, be warned that I did try implementing this way and it turned out tob be even more buggy and unmaintainable.

As far as I remember, the bug was someone was trying to do something very weird that even CMake doesn't support for boost. I am not certain, why Meson should support weird, not officially supported by the boost team scenarios, for the cost of normal, supported scenarios. It goes against the core of Jussi's philosophy, which Jussi reiterated himself many times. Meson should support what boots officially supports, no more, which is currently CMake files. I would encourage you to resurrect your implementation, but reevaluate what you consider a "bug".