mpv-player/mpv

Default meson library prefix behavior?

DeadSix27 opened this issue · 6 comments

With waf the windows builds usually had the library without prefix (e.g mpv-2.dll, which is the windows standard)
with meson this isn't the case, despite the doc stating:

By default this is lib on all platforms and compilers, except for MSVC shared libraries where it is omitted to follow convention, and Cygwin shared libraries where it is cyg.

I assume its because I'm compiling with mingw rather than MSVC and meson doesn't consider that..

Should this be handled by mpv or reported upstream to meson or what?

In meson.build, the library function is just:

libmpv = library('mpv', sources, dependencies: dependencies, gnu_symbol_visibility: 'hidden',
                 version: client_api_version, include_directories: includedir, install: true)

So we're just doing whatever the default is and not setting any prefix.

I know.. so maybe add something like master...DeadSix27:mpv:lib-prefix-variant-2 to set it automatically

or master...DeadSix27:mpv:lib-prefix-variant-1

to give one the option

Having to workaround this sounds completely wrong and defeats the purpose of using a build system in the first place. Unless there's just some random option/flag we're just missing, this should be a meson thing imo.

Seems some projects check for windows and then set "name_prefix" accordingly in the meson file, for example mesa does the same as I suggested https://gitlab.freedesktop.org/mesa/mesa/-/commit/67627c84a71b4c795efa6ddcffa5633ce0239f65

Is that really necessary though? To me it seems weird to have to define an ad-hoc prefix just for one operating system.

For the software I compile on windows I tend to use /usr/ as prefix too, e. g. C:\usr\ or however the name is then called on windows. That actually works quite decently.

Is that really necessary though? To me it seems weird to have to define an ad-hoc prefix just for one operating system.

For the software I compile on windows I tend to use /usr/ as prefix too, e. g. C:\usr\ or however the name is then called on windows. That actually works quite decently.

It's about the library prefix (of the file name), not the install prefix