protonscr

RFC: Build system improvements (again)

dxvkclosed
doitsujin/dxvk#1189 · opened 2019-09-11 by pchome · updated 2019-09-13 · 5 comments · github
Ppchome 2019-09-11 github

Description

People want more compiler/options variants, which are hard to support and which became insane in the meson.build file. Let's isolate this variations in the separate directory structures, so if one want support new "compiler-name" compilation, it will be easy to do so, by copy/patch files somewhere else, not touching main meson.build.

Idea

  1. Create e.g. compiler/ directory w/ the following structure:

    compiler/clang/
compiler/gcc/
compiler/mingw-clang/
compiler/mingw-gcc/
compiler/msvc/
compiler/wine-clang/
compiler/wine-gcc/

  2. Each can contain whatever they need to compile DXVK (additional includes/files/etc.), cross-files and meson.build.

  3. The meson.build file should contain what currently under corresponding condition in the main meson.build file.
    e.g. for winelib: https://github.com/doitsujin/dxvk/blob/master/meson.build#L28-L49

  4. All conditions then could be replaced by the following code

    # compiler_specific_files='compiler/wine-gcc', defined in compiler/wine-gcc/buld-wine64.txt
# 'compiler/mingw-gcc' - default fallback
dxvk_compiler_dir = meson.get_cross_property('compiler_specific_files', 'compiler/mingw-gcc')
subdir(dxvk_compiler_dir)

    or

    if dxvk_winelib
  subdir('compiler/wine-gcc')
else

Clarification

Based on how Meson subdir() command work

Enters the specified subdirectory and executes the meson.build file in it. Once that is done, it returns and execution continues on the line following this subdir() command. Variables defined in that meson.build file are then available for use in later parts of the current build file and in all subsequent build files executed with subdir().

If "mingw-gcc" is default and only supported compiler, then not necessary to create compiler/mingw-gcc/ directory for it. You can keep it's parts as-is, just drop everything else and add the ability to redefine variables.

Well, then just forget about those files, no need to support them. Anyone, who use them, will be able to create PR to improve/fix corresponding compilation.

Mics

Also, later, it may be worth to define more generic names for some lower-level variables, to be redefined. E.g. d3d11_shared_objects= (d3d11_shared_(defs|overrides|...)=, found in src/d3d11/meson.build).

More of possible change candidates: d3d10_deps= and other places/variables with conditions, shared library names, etc.

Conclusion

Just a basic idea. I could create this in practice and PR, if it worth so.

Theoretically should help "clang"/"dxvk-native"/"macOS"/... users. Also "winelib", to not being completely dropped ;)

Ddoitsujin maintainer 2019-09-11 github

Isn't the current build system already complicated enough? Why do we need to support even more setups in even worse ways?

Ppchome 2019-09-11 github

The idea is to simplify it for you, in the first place. AFAIK, you don't want to support other compilers than mingw. In the second place -- the ability to just copy custom files into compilers/compiler-name/ w/o additional changes to all meson.build files.

So the meson.build file will look like it written for mingw, with only one condition to include third-party directory, which will be supported by the others, or left as-is, not your problem. But yes, the final solution can be worse. That's why asking.

In particular, I remembered about "dxvk-native", and finally tried to build it. I don't know what the status of this patch, but it trying to mess with the build system even more. Maybe such changes should help to simplifiy the patch, idk. @Guy1524 ?

GGuy1524 2019-09-12 github

@pchome I'll have to look back at my patch to see if this is desirable, but I think the bigger issue was that my patch involved a lot of compiler directives scattered around.

Ppchome 2019-09-12 github

@Guy1524
It's possible to disable dxgi and d3d10 build using -Denable_dxgi=false and -Denable_d3d10=false meson options. Also, maybe you could use -D__WINE__=1 along with -DDXVK_NATIVE=1, this should slightly reduce the patch size.

Talking about custom targets, that could be one more "compiler/" include right after subdir('src') and build_by_default option for all targets, to control. I such case it will be possible to use all DXVK's *_src= variables for custom target, defined in corresponding "include".

Ppchome 2019-09-13 github

I should stop doing dirty hacks (lazybones).

I remembered, I already tried to do something like this a while ago, and that was rather bad idea.

Nothing extracted yet.