Install headers and pkg-config files by smcv · Pull Request #3325 · doitsujin/dxvk

smcv · 2023-03-31T15:06:55Z

This is just a prototype at this stage, and I haven't gone all the way down the stack to distro-style packages to test it. I'm aware DXVK isn't yet officially API- and ABI-stable, but I want to go through the motions of packaging it before it gets to that point, so that if there are any blockers that involve incompatible changes they can be resolved before it's too late.

It probably doesn't make sense to install the pkg-config files and headers until DXVK is officially API- and ABI-stable, but some of the refactoring on the way might be useful.

Based on #3324.

build: Omit v prefix from the version number

It's conventional for version numbers to start with a digit. This isn't
important yet, but will become significant when generating pkg-config
metadata that can be queried for a sufficient version number.
Set the stem of library names instead of the name_prefix

This is necessary for compatibility with Meson's pkg module, which
generates pkg-config metadata containing "-lNAME" where NAME is the
first argument to shared_library(). Changing the name_prefix parameter
would break that.

Conversely, including .dll or .so in the first parameter would also
break that, so remove the +dll_ext part (in practice this is not a
functional change, because dll_ext is always set to an empty string).
build: Use Meson default mechanisms to find WSI dependencies

The dependency name sdl2 is special-cased to be found via either
pkg-config or sdl2-config.

glfw3 will be found via pkg-config, as recommended in its build
documentation.

This allows use of a SDL or GLFW library that is not in the compiler's
default search paths, and is also useful when using pkg.generate():
a dependency on a library found via pkg-config will result in the
generation of correct Requires.private in dxvk's own pkg-config metadata.
build: Install headers for native builds

When building a game that has been ported to Linux using DXVK Native,
these headers are necessary to provide the Direct3D and DXVK APIs.
Set the stem of library names instead of the name_prefix

This is necessary for compatibility with Meson's pkg module, which
generates pkg-config metadata containing "-lNAME" where NAME is the
first argument to shared_library(). Changing the name_prefix parameter
would break that.

Conversely, including .dll or .so in the first parameter would also
break that, so remove the +dll_ext part (in practice this is not a
functional change, because dll_ext is always set to an empty string).
build: Use Meson default mechanisms to find WSI dependencies

The dependency name sdl2 is special-cased to be found via either
pkg-config or sdl2-config.

glfw3 will be found via pkg-config, as recommended in its build
documentation.

This allows use of a SDL or GLFW library that is not in the compiler's
default search paths, and is also useful when using pkg.generate():
a dependency on a library found via pkg-config will result in the
generation of correct Requires.private in dxvk's own pkg-config metadata.
build: Install headers for native builds

When building a game that has been ported to Linux using DXVK Native,
these headers are necessary to provide the Direct3D and DXVK APIs.
build: Generate pkg-config metadata to link to DXVK libraries

This allows dependent projects to query the version and location of DXVK
via the pkg-config interface.

The include directories aren't yet set, because the headers aren't
installed; that will follow in a subsequent commit.

The naming of these pkg-config files is based on proposed Fedora packages
for DXVK 2.0, and is not compatible with older Fedora packages for DXVK
1.x (which used the naming convention dxvk-native-d3d9 and so on).
Packagers can create symlinks such as dxvk-native-d3d9.pc -> dxvk-d3d9.pc
if they want to retain compatibility with older names.

Selecting the GLFW WSI gives DXVK an incompatible ABI: for example, CreateDevice takes a `SDL_Window *` parameter in the default SDL WSI, but takes a `GLFWwindow *` instead in the GLFW WSI. This means it should get a different name, so that binaries expecting one WSI don't unexpectedly load the other. Resolves: doitsujin#3321 Signed-off-by: Simon McVittie <smcv@collabora.com>

It's conventional for version numbers to start with a digit. This isn't important yet, but will become significant when generating pkg-config metadata that can be queried for a sufficient version number. Signed-off-by: Simon McVittie <smcv@collabora.com>

This is necessary for compatibility with Meson's pkg module, which generates pkg-config metadata containing "-lNAME" where NAME is the first argument to shared_library(). Changing the name_prefix parameter would break that. Conversely, including .dll or .so in the first parameter would also break that, so remove the `+dll_ext` part (in practice this is not a functional change, because `dll_ext` is always set to an empty string). Signed-off-by: Simon McVittie <smcv@collabora.com>

The dependency name `sdl2` is special-cased to be found via either pkg-config or `sdl2-config`. `glfw3` will be found via pkg-config, as recommended in its build documentation. This allows use of a SDL or GLFW library that is not in the compiler's default search paths, and is also useful when using pkg.generate(): a dependency on a library found via pkg-config will result in the generation of correct Requires.private in dxvk's own pkg-config metadata. Signed-off-by: Simon McVittie <smcv@collabora.com>

When building a game that has been ported to Linux using DXVK Native, these headers are necessary to provide the Direct3D and DXVK APIs. Signed-off-by: Simon McVittie <smcv@collabora.com>

This allows dependent projects to query the version and location of DXVK via the pkg-config interface. The include directories aren't yet set, because the headers aren't installed; that will follow in a subsequent commit. The naming of these pkg-config files is based on proposed Fedora packages for DXVK 2.0, and is not compatible with older Fedora packages for DXVK 1.x (which used the naming convention dxvk-native-d3d9 and so on). Packagers can create symlinks such as dxvk-native-d3d9.pc -> dxvk-d3d9.pc if they want to retain compatibility with older names. Signed-off-by: Simon McVittie <smcv@collabora.com>

smcv · 2023-03-31T15:08:55Z

+  if dxvk_wsi == 'sdl2'
+    dxvk_name_prefix = 'dxvk_'
+    dxvk_pkg_prefix = 'dxvk-'
+  else
+    dxvk_name_prefix = 'dxvk_@0@_'.format(dxvk_wsi)
+    dxvk_pkg_prefix = 'dxvk-@0@-'.format(dxvk_wsi)
+  endif


It's a bit unfortunate that one of these is dxvk_ and the other is dxvk-. I've kept the naming from the Fedora packaging for now, but I'd be very tempted to change it to dxvk_d3d9.pc, dxvk_glfw_dxgi.pc and so on, to be consistent with the library names and avoid having two subtly different name-prefixes.

It is unfortunate that Meson's pkgconfig module doesn't support setting Provides:. That would neatly resolve the issue, I think.

smcv · 2023-03-31T15:10:21Z

+
+if platform != 'windows'
+  pkg.generate(d3d10_core_dll,
+    filebase: dxvk_pkg_prefix + 'd3d10core',


If the prefix was dxvk_ rather than dxvk-, I think we could omit filebase here completely, and just let Meson deduce it from the shared_library.

smcv · 2023-03-31T15:10:48Z

+if platform != 'windows'
+  pkg.generate(d3d10_core_dll,
+    filebase: dxvk_pkg_prefix + 'd3d10core',
+    subdirs:  'dxvk',


This must be consistent with the subdirectory we install into in include/native/meson.build, but is otherwise arbitrary.

smcv · 2023-03-31T15:18:18Z

+install_subdir(
+  'directx',
+  install_dir: get_option('includedir') / 'dxvk',
+  strip_directory: true,
+)
+
+install_subdir(
+  'windows',
+  install_dir: get_option('includedir') / 'dxvk',
+  strip_directory: true,
+)
+
+install_headers(
+  'wsi/native_wsi.h',
+  'wsi/native_@0@.h'.format(dxvk_wsi),
+  subdir: 'dxvk/wsi',
+)


This assumes that dependent code would be correct to do things like:

#include <d3d9.h> #include <windows.h> #include <wsi/native_wsi.h>

and then compile with something like

$(CC) ... `pkg-config --cflags --libs dxvk-d3d9`

which would typically expand to something like -I/usr/include/dxvk -ldxvk_d3d9. Is that the intention?

Normally it's a matter of opinion whether to install headers directly into ${includedir} (like e.g. libjpeg and libwayland), or install them into ${includedir}/${package} and requiring library users to specify an appropriate -I option for parallel-installability (like GTK and vkd3d).

But for DXVK Native specifically, when the headers that are installed include something as namespace-grabbing as windows.h, I don't think there's really any alternative to installing into a subdirectory. I arbitrarily chose dxvk, but it can be anything (dxvk-2.x or dxvk-native or even dxvk/native would be equally good), as long as it's consistent between here and the pkg.generate() calls. It's the equivalent of the vkd3d in /usr/include/vkd3d or the gtk-3.0 in /usr/include/gtk-3.0.

FYI: gitmodules and subprojects are not included in github generated source tarballs.
directx directory will be empty in this case.

Building DXVK from a github-generated source tarball cannot be supported as long as it needs submodules (this is already true, I'm not changing that here). Currently, it either needs to be built from a recursive git clone, or via some process that vendors the necessary submodule code.

That's probably better discussed on a new issue report rather than here.

smcv · 2023-03-31T15:29:24Z

-    lib_sdl2 = cpp.find_library('SDL2')
+    sdl2_dep = dependency('sdl2')
    compiler_args += ['-DDXVK_WSI_SDL2']
  elif dxvk_wsi == 'glfw'
-    lib_glfw = cpp.find_library('glfw')
+    glfw_dep = dependency('glfw3')


This isn't working as I'd hoped yet: it's not generating a Requires.private: sdl2 in the .pc files. I think that's probably because the shared libraries pick up their dependency on SDL/GLFW via a chain of static libraries, rather than explicitly depending on it. More adjustment needed there.

flibitijibibo · 2024-05-22T16:22:54Z

This got obsoleted by #3834

smcv added 6 commits March 31, 2023 14:36

build: Install headers for native builds

f25917c

When building a game that has been ported to Linux using DXVK Native, these headers are necessary to provide the Direct3D and DXVK APIs. Signed-off-by: Simon McVittie <smcv@collabora.com>

smcv force-pushed the pkgconfig branch from f2675da to 4c4bf49 Compare March 31, 2023 15:16

smcv commented Mar 31, 2023

View reviewed changes

smcv mentioned this pull request Dec 7, 2023

[native] Establish a libdxvk ABI #3451

Closed

3 tasks

flibitijibibo mentioned this pull request Feb 4, 2024

Install headers and pkg-config files, MkII #3834

Merged

doitsujin closed this May 24, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Install headers and pkg-config files#3325

Install headers and pkg-config files#3325
smcv wants to merge 6 commits into
doitsujin:masterfrom
smcv:pkgconfig

smcv commented Mar 31, 2023

Uh oh!

smcv Mar 31, 2023

Uh oh!

Conan-Kudo Dec 18, 2023

Uh oh!

smcv Mar 31, 2023

Uh oh!

smcv Mar 31, 2023

Uh oh!

smcv Mar 31, 2023

Uh oh!

smcv Mar 31, 2023

Uh oh!

pchome Apr 1, 2023

Uh oh!

smcv Apr 3, 2023

Uh oh!

smcv Mar 31, 2023

Uh oh!

flibitijibibo commented May 22, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

smcv commented Mar 31, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

flibitijibibo commented May 22, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants