Dxvk: Better deployment of dll for setup_dxvk.sh

[shmerl]

To make setup_dxvk.sh more unified (i.e. one script for all scenarios), it can be useful to rearrange dlls deployment a bit. For example:

./bin
./bin/setup_dxvk.sh
./lib
./lib/win64/dxgi.dll
./lib/win64/d3d11.dll
./lib/win64/d3d10core.dll
./lib/win64/d3d10.dll
./lib/win64/d3d10_1.dll

This will allow cleaner placement of 32-bit dlls. While .so ones can be deployed cleanly now in the same parent location, dlls are not since they are placed in bin.

I.e. adding this would make it work:

./lib/win32/dxgi.dll
./lib/win32/d3d11.dll
./lib/win32/d3d10core.dll
./lib/win32/d3d10.dll
./lib/win32/d3d10_1.dll

If you think it's a good idea, I can update my PR to do that.

[doitsujin]

Why would you want to rearrange the files, and what's the fuss about something that's meant for development purposes only? Remember that every change to this also changes my workflow.

[shmerl]

Just to reduce directory clutter. Using such approach you can place everything in one location. This isn't useful just for development purposes, but for any deployment.

For instance current Debian packages use such format:
https://packages.debian.org/buster/amd64/dxvk-wine64-development/filelist

```/usr/lib/dxvk/wine64-development/d3d10.dll.so
/usr/lib/dxvk/wine64-development/d3d10_1.dll.so
/usr/lib/dxvk/wine64-development/d3d10core.dll.so
/usr/lib/dxvk/wine64-development/d3d11.dll.so
/usr/lib/dxvk/wine64-development/dxgi.dll.so
/usr/lib/dxvk/wine64-development/setup_dxvk.sh

https://packages.debian.org/buster/i386/dxvk-wine32-development/filelist

/usr/lib/dxvk/wine32-development/d3d10.dll.so
/usr/lib/dxvk/wine32-development/d3d10_1.dll.so
/usr/lib/dxvk/wine32-development/d3d10core.dll.so
/usr/lib/dxvk/wine32-development/d3d11.dll.so
/usr/lib/dxvk/wine32-development/dxgi.dll.so
/usr/lib/dxvk/wine32-development/setup_dxvk.sh
```
To add dll to that cleanly will add 2 more .sh scripts?

Making one dxvk root with 4 sublocations (2 for 32/64-bit dll 2 for 32/64-bit so) and one script to set any of them is neater. But it's not a major issue of course.

[doitsujin]

If the debian package actually ships the .sh script like that then someone should tell them that this is a bad idea. If they want DXVK to be set up via symlinks, which is of course a good thing, they should probably put a small script in themselves that points to the correct locations, but this is distro-specific.

I can also see why the current script is less than ideal, but it's not an easy fix since it is being generated during the build process, i.e. once for the 64-bit build and once for the 32-bit build.

[shmerl]

I can also see why the current script is less than ideal, but it's not an easy fix since it is being generated during the build process, i.e. once for the 64-bit build and once for the 32-bit build.

That can be changed by making the script static (not generated), and more generic without templatizing it in the build. Kind of the idea I was going in the PR with external variables controlling the changing parts.

But sure. May be simply writing an alternative script will work as well. I can propose it to Debian maintainers or write one myself first.

[doitsujin]

That can be changed by making the script static (not generated), and more generic without templatizing it in the build.

Yes, but then you basically can't do ninja install and have a working script either.

[shmerl]

By the way, why after building 32-bit / winelib variant, ninja install produces .a files in 64-bit subdirectory?

./lib/x86_64-linux-gnu
./lib/x86_64-linux-gnu/dxgi.dll.a
./lib/x86_64-linux-gnu/d3d11.dll.a
./lib/x86_64-linux-gnu/d3d10core.dll.a
./lib/x86_64-linux-gnu/d3d10.dll.a
./lib/x86_64-linux-gnu/d3d10_1.dll.a

In fact even .so files are also going in x86_64-linux-gnu in such case instead of let's say .../lib/i386-linux-gnu/...

I guess it just picks up the build arch for the name. I'm working on the custom setup_dxvk.sh for better layout.

[SveSop]

@shmerl If debian is as bad as ubuntu (which is based on debian), then the winelib build script does not work without the meson build option for --libdir=, cos building it without manually moving the files will just build everything in the x86_64-linux-gnu folder (and overwrite 64-bit dll.so's with 32-bit ones..)

Not really sure why this happens, but ubuntu's crossbuild system kinda blows that way (debian probably better tho)

You can try with the "meson --libdir=lib" option when building and see if it is any better/logical.

[Thaodan]

@shmerl As the base version of dxvk is just a mingw build you could use the corresponding mingw prefix.
For example arch as a 32bit and 64bit mingw prefix:
https://wiki.archlinux.org/index.php/MinGW_package_guidelines#Packaging

[shmerl]

then the winelib build script does not work without the meson build option for --libdir=, cos building it without manually moving the files will just build everything in the x86_64-linux-gnu folder (and overwrite 64-bit dll.so's with 32-bit ones.

Yep, that's indeed what happens in Debian too. I'll try experimenting with --libdir.

[shmerl]

btw, here is a way to automate detection of wine arch for a given prefix, in case someone needs it.

Used here.

[shmerl]

OK, I tested. --libdir does affect where .so and .a files are placed after build, but not the dll ones.

[shmerl]

I can control dlls placement with --bindir, but that also relocates setup_dxvk.sh there. So splitting that into a separate option (keeping it default same as current layout) can probably help.

[shmerl]

Looks like bindir is Meson's builtin. So may be making a separate variable for the script would help.

[shmerl]

Yep, this worked. Added this to meson_options.txt

option('utilsdir', type: 'string', value : '')

And this to utils/meson.build

conf = configuration_data()
conf.set('bindir', get_option('bindir'))
conf.set('libdir', get_option('libdir'))
conf.set('arch', target_machine.cpu_family())
conf.set('winelib', dxvk_winelib)

utilsdir = get_option('utilsdir')
if utilsdir == ''
  utilsdir = get_option('bindir')
endif

configure_file(
  configuration : conf,
  input         : 'setup_dxvk.sh.in',
  output        : 'setup_dxvk.sh',
  install_dir   : utilsdir
)

Then invoking meson works something like this:

meson \
--cross-file $cross_file \
--libdir lib64 \
--bindir lib64 \
--prefix ${dest_dir} \
-Dbuildtype=release \
-Dutilsdir=bin \
"$dxvk_build"

And by default it's still keeps current behavior (using bindir for the utils).

[shmerl]

I can make a PR with this.

[SveSop]

I dont think i have really grasped the purpose of this tbh. What is the goal? Create a system installable package that can set up the dll-overrides for a given WINEPREFIX running the setup_dxvk.sh script?

I'm kinda slow when understanding stuff tho, but are happy to take information on a spoon-fed-for-dummies approach :)

[shmerl]

The purpose is simple, to be able to reduce clutter and place *.dll and *.so in the same directory, let's say dxvk/lib64 (and dxvk/lib32 for 32-bit variants). While placing just a single installation script in dxvk/bin, that could properly handle both 64-bit and 32-bit prefixes.

[SveSop]

So the package_release.sh script should build both mingw-w64 and winelib in one go? Cos using dxvk/lib64 vs. todays dxvk/x64 (and lib32 vs x32) seems kind of moot point of changing scripts to me, unless you want to make a new script that builds both winelib and mingw-w64 at the same time.. in the same folder.. keeping both the .verb script for winetricks AND a separate installscript in dxvk/bin

[shmerl]

I'm not using package_release.sh really, but yeah, I commonly simply build all 4 (mingw and winelib, each 64 and 32-bit), and then place them like above:

dxvk/lib64 - all 64 bit libs
dxvk/lib32 - all 32 bit libs
dxvk/bin - utils (dxvk install script).

The problem is not with lib / x (I'm fine with x32 / x64 notation), but with dlls ending up in bin right now, and with dxvk_setup.sh turning 32 / 64 bit specific.

[SveSop]

Building with the script is quite nice tbh, so i would recommend to do that. Don't see the point in messing with meson build options or stuff like that, if you can use the script to do what you want?

Tossed together a "multi-script" that would build both if no options given.
echo "Usage: package-release.sh version destdir [--no-dll] [--no-winelib] [--no-package]"

Take a look at it. Puts the dxvk_install.sh script in dxvk/bin folder.

The install script itself needs to be looked at to get it working ofc, but that should be equally doable i guess, so you can set options if you want winelib dll.so's symlinked or whatnot.
package-release.sh.gz

[shmerl]

Thanks, I'll take a look. I got the impression there is no way to control where dlls are placed (they always go in bin) during the meson build and install phase itself. That's why I thought of expanding Meson options to split location of dlls and dxvk_setup. Later you can of course move them around any way you want using extra deployment scripts.

[SveSop]

When meson builds the winelib build, the placement is controlled by the --libdir= statement, and you can do this in the script. I used --libdir=lib, but you can use whatever you like, but the script clears out the build-folders anyway, so it does not matter.

meson --cross-file build-wine64.txt --buildtype release --libdir=lib64 --strip --prefix $HOME/dxvk build.w64

Will make the builddir build.w64 and running ninja install in that folder will build dll.so's that get put in $HOME/dxvk/lib64 (ref. --libdir=lib64 .. name whatever you like). Now do the same for build-wine32.txt , just replacing "64" with "32", and they get put there.

[shmerl]

Right, the problem is not winelib, but mingw build. dlls always go to bindir. So the hack I thought of was, to set bindir to the same as libdir, and then place install script in another parameterized location, which is the real bin.

[SveSop]

Ah, then i misunderstood you, cos you mentioned winelib build earlier, so i thought you were messing with that. Most ppl use the included package-release.sh script i guess, and that just moves the files from the "prefix" folder.

So, if you use meson --cross-file build-win64.txt --buildtype release --strip --libdir=lib --prefix $HOME/dxvk build.w64 the dll's are being put in /bin, and the .a files are being put in /lib.

Yeah, that was unexpected. Using prefix $HOME/dxvk/lib64 and --lib=lib64 will put everything in the lib64 folder INCLUDING the setup_dxvk.sh script.

Yeah, as i said in an earlier post: I need to be spoon-fed-for-dummies what ppl are trying to do :+1:

I think mingw-w64 looks at .dll files as "bin", as they are not libraries perhaps? In the "windows world" the .dll files many times gets put in the same folder as the .exe, and thus MIGHT be considered as "bin".. dunno, but it would not surprise me if the logic behind dll's always being put in the --bindir folder is due to something like that.

[shmerl]

Well, dlls are as much libraries as .so are. Same dynamic loading idea. But if you mean that package-release.sh can shuffle them in the final result from bin to libdir, that's good enough of course.

[SveSop]

That is a script, so you can make that do whatever you like.

I wonder tho, if there might be some install_dir tinkering in meson.build file to make this happen perhaps? If not set, it will use "default behavior" and i guess that is to put dll's into /bin. But i dont really know much about meson or most things :)

[SveSop]

Ah well.. You have to add:
install_dir : get_option('libdir'),
to the meson.build files for d3d11, d3d10, dxgi , and then specify --libdir= like this:
meson --cross-file build-win64.txt --buildtype release --strip --libdir=lib64 --prefix $HOME/dxvk build.w64
meson --cross-file build-win32.txt --buildtype release --strip --libdir=lib32 --prefix $HOME/dxvk build.w32
That should put the dll's (and the .a files) in the --libdir= folder of your choosing.

The meson.build file in d3d10 need this for all the dll's sections, so should be 3 (d3d10, d3d10_1 and d3d10core).

@doitsujin This will break the current script tho, but is this something to be considered? Perhaps get away with the whole cp "$DXVK_BUILD_DIR/install.$1/bin/..... section of the script, as the files are put in the correct spot. Using --libdir=x$1 in the script would keep the current file placement intact for any winetricks verbs or whatnot in use, so it would not be a huge difference to the end-result.
If its something you would consider, i can put up a PR with changes, but if you deem its of no interest, @shmerl have gotten his answer for personal tinkering.

[SveSop]

@shmerl If you want to fiddle with it, you can apply this patch in the dxvk folder:
dxvk_build.patch.gz

You can either use the above meson lines, or try out the "multi-build" script.

[shmerl]

The current behavior can be kept, by introducing an optional parameter, for example dlldir. If it's set, install_dir can be assigned to that, and if not, it can be assigned to current default bindir. This way @doitsujin's workflow can be kept, and custom location can still be set during build with -Ddlldir=lib64 for example.

To make it more consistent, dxvk_setup.sh will still need some modifications.

[SveSop]

If the --libdir= is not used, the "default" behavior is to the /bin folder. No need to introduce a new parameter.
So i guess the easiest would be to set install_dir in the meson files, and not specify --libdir= when building to keep things as it is. So one would have the option to change if needed perhaps?

Took a quick look at the setup_dxvk.shscript, and it only has the option to install to either x86 or x86_64 by manual change. This could be optimized so it actually install both 32bit and 64bit when you have a 64-bit prefix.

The package-release.sh script does not keep the /bin folder with the setup_dxvk.sh script in its current form tho, as its not copied over. Probably oki, as its not working that well anyway.

[shmerl]

It's working quite fine for me. To enhance it, it should autodetect the architecture from the registry in the prefix (or WINEARCH variable), I posted example above. It also should allow setting winelib flag externally instead of hardcoding it. Plus it should know how to name both 64 and 32-bit libdirs. Doing that it would be able to handle all cases without modifications to the script itself.

[SveSop]

Tried to look at creating a setup_dxvk.sh script suiting both 32 and 64-bit prefixes, but i dont have the l33t skillz enough to get it working properly...

The reason why it defaults to installing it in each /bin folder, is cos it creates 2 scripts, 1 for each of the arch's when creating overrides and symlinks. The ideal would be as outlined above - the dll's/dll.so's get put in the x32/x64 folders, and 1 dxvk_setup.sh script in the /bin folder.

There is ofc ways of detecting if its a 32 or 64 bit prefix by using winepath and distinguising between system32 and syswow64, but as i said, my scripting skills is lacking in the manner of making the symlinks point to their respective arch version of dll's was not trivial (for me).

In a 32-bit wineprefix, c:\windowssystem32 is the folder for 32-bit symlinks to x32/.dll.so, but in a 64-bit wineprefix, c:\windowssystem32 should point to 64-bit x64/dll.so's, and c:\windowssyswow64 to x32/*.dll.so. Combining this in a single script with detection is probably easy for someone but me...

#!/bin/bash

WINESYSDIR=$( winepath -u c:\\windows\\system32 )    
if [[ ${WINESYSDIR} == *"/system32" ]]; then
  echo "Prefix is 32 bit"
  # do 32 bit stuff here...
elif [[ ${WINESYSDIR} == *"/syswow64"* ]]; then
  echo "Prefix is 64 bit"
  # do 64 bit stuff here...
else
  echo "Unknown wine architecture"
fi

WINEPREFIX=/yourprefix ./script_above.sh

will figure out if its a 32 or 64 bit prefix...

[shmerl]

You don't need to wrangle paths, just check the set wine arch, and assume that's the set of libraries you need.

See how such detection is done here.

[shmerl]

I'll get back to this a bit later.

[SveSop]

Tinkered a bit with it.. with the little knowledge i have.. but came up with a working script that detects if the WINEPREFIX is a x86, or a x86_64 one, and create links accordingly.
Added option -winelib if you want to symlink to the dll.so's. If the option is omitted, normal symlinking to .dll happens.
eg.
WINEPREFIX="/your/wine/prefix" ./setup_dxvk.sh install -winelib
Assuming its run from the dxvk/bin folder, and the dll's and dll.so's are located in their respective x32 and x64 folders. (Ref. my previous patch above).

You can take a look at it.
setup_dxvk.sh.gz

[shmerl]

I think using wow64 directories isn't always a good idea, since not every wine is WoW variant. I.e. you can have 64-bit prefix without wow64 I think. The best way is to read wine configuration from $WINEPREFIX/system.reg. It would have one of these two:

For 64-bit:

#arch=win64

For 32-bit:

#arch=win32

Also, taking in account WINEARCH variable makes sense (if it's set). The function I linked above does exactly that.

[SveSop]

No, you cannot have a x86_64 bit wineprefix without c:\windows\syswow64 This started when XP first came with 64-bit versions afaik.
So, if you create a 64-bit wineprefix with a recently modern wine (2.x+) this WILL happen.

The reason for fiddling with the syswow64 and system32 folders, is not to "detect wine arch", but to actually create 32 and 64 bit links in the correct place. You WILL run into problems if you put symlinks to 32-bit dll's in the c:\windowssystem32 folder on a 64-bit WINEPREFIX.

Dont intermingle "WoW" with wow64 and syswow64 :) WoW = World of Warcraft, wow64 = ?, syswow64 = 32-bit in a 64-bit windows installation. (Although the logic behind that med me fumble my first dxvk install a wee bit back).

http://www.samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm

[shmerl]

WoW64 stands for Windows on Windows 64-bit (a weird name, I know).

See https://wiki.winehq.org/Building_Wine#Shared_WoW64

Anyway, presence of directory is not a good indicator, even if it was created. For instance, you can make a 64-bit prefix, and convert it to 32-bit prefix. The directory can still be lingering around. But the value in system.reg should be always correct.

[SveSop]

Probably best to read it from registry for those cases where ppl do things they are not supposed to, but i would not choose to use a perl scrip to do that tho. Not sure how i get wine to output that through regedit?

[SveSop]

That script you linked searches for win64 in the registry, and there are loads. And i guess if you convert from 64 -> 32 bit somehow, this may be lingering anyway.

However
WINEPREFIX="/your/wine/prefix" wine reg QUERY "HKLM\System\CurrentControlSet\Control\Session Manager\Environment" /v PROCESSOR_ARCHITECTURE
Will read out
PROCESSOR_ARCHITECTURE REG_SZ x86 on 32-bit wineprefix, and
PROCESSOR_ARCHITECTURE REG_SZ AMD64 on a 64-bit wineprefix.

Might be useful?

[SveSop]

Test this
setup_dxvk.sh.gz

[shmerl]

Probably best to read it from registry for those cases where ppl do things they are not supposed to, but i would not choose to use a perl scrip to do that tho. Not sure how i get wine to output that through regedit?

You can use it with pure bash. Bust read the file and catch regexes using something like
[[ "$line" =~ $regex ]] and ${BASH_REMATCH[<index>]} for capture groups (ones defined in brackets in your regex).

Using perl is just neater for that case, because I like Perl regex syntax a lot more. At least it's not any worse than using sed which is also an external tool.

[shmerl]

If you don't want to manually fish out special comments from the registry file, your method with wine reg also works, but it's a bit heavy (compared to perl).

[SveSop]

You can test my latest script updates on my github repo https://github.com/SveSop/dxvk.git
echo "Usage: package-release.sh version destdir [--winelib] [--no-package]"
eg
./package_release.sh git $HOME/winestuff --no-package
This will build dxvk as mingw-w64 dll's and put the dxvk_git folder in $HOME/winestuff
In dxvk_git/bin you have setup_dxvk.sh that will install or uninstall + create overrides for your WINEPREFIX. It detects arch by checking registry, and it does a wineboot -u to recreate any missing fake-dlls and so on.
eg.
WINEPREFIX="$HOME/.wine" ./setup_dxvk.sh install

If you build dxvk with eg:
./package_release.sh git $HOME/winestuff --winelib --no-package
It will create the same folder as above, but with the dll.so winelibs instead.
The script works in the same manner, as it will create symlinks for dll.so. (eg. d3d11.dll -> d3d11.dll.so symlink).

Result: We would have 1 buildscript that you can choose to build mingw-w64 dll's, or winelib dll.so AND it is 1 script that creates symlinks and dll-overrides depending on if its a winelib build or mingw-w64 build. The winetricks .verb is not changed.

@doitsujin Is this something to consider? Take a look if you have the time to it. Foldernames and everything is the same, and buildoptions is the same, exept if you choose to give it --winelib as an option to make it build winelib dll.so.

[shmerl]

Result: We would have 1 buildscript that you can choose to build mingw-w64 dll's, or winelib dll.so AND it is 1 script that creates symlinks and dll-overrides depending on if its a winelib build or mingw-w64 build

Can it create it for both? My idea was to place both winelib and mingw libraries in once place, and use a single script to manage them all (depending on some set environment variable or script parameter).

I.e. it would be good to take out the script from the build time templatization, except for location of 32 and 64 bit libdirs.

[SveSop]

It can be modified so it builds both versions - winelib and mingw-w64 and put them in the same place, and then the install script to take a parameter for what you want?
eg.
setup_dxvk.sh install winelib or setup_dxvk.sh install dll

Something like that?

[SveSop]

Oki - https://github.com/SveSop/dxvk/commit/5b4c3b769942b3c178332065a2eef6298370d519
Buildscript with the following options:
Usage: package-release.sh version destdir [--no-winelib || --no-dll] [--no-package]
If nothing is specified eg:
./package-release.sh git $HOME/winestuff --no-package
Both mingw-w64 dll's and winelib dll.so's are being built and placed in their respective x32/x64 folders. You can then opt-out of building one of them if choosing --no-dll or --no-winelib

Installscript with the following option:
Usage: $0 [install|uninstall] [dll|winelib] [-q|--quiet] [-y|-n]
eg
./dxvk_setup.sh install dll will create symlinks + overrides for dll's
./dxvk_setup.sh install winelib will create symlinks + overrides for dll.so's

Installscript only gets built via meson.build to be placed in the /bin folder. No other arguments passed. If different 32/64 bit lib dirs are to be used - other than x32 and x64 it might hamper already used winetricks verb and other stuff, so i did not change this.... so far x32 and x64 will have to do.

[shmerl]

It can be modified so it builds both versions - winelib and mingw-w64 and put them in the same place, and then the install script to take a parameter for what you want?
eg.
setup_dxvk.sh install winelib or setup_dxvk.sh install dll

Something like that?

Yes, something of the sort. I'll play around with your script.

[SveSop]

There are some issues with doing this tho. One is that changing the meson.build files will make ppl need to update buildscripts I think. PKGBUILD scripts that build without the --libdir= statement will face issues and needs updating.

The other problem is that I don't know any way to combine both x86 and x86_64 builds into making 1 setup_dxvk.sh script. As it is now, it builds the script twice, but since i don't import any settings really, it works fine, but it SHOULD use the build --libdir= statement, cos if you build manually and dont use the package-release.sh it will fail.
There is nothing stopping you from doing a manual meson build with --libdir=winedll_AMD64 or whatever, and the setup_dxvk.sh script will not pick this up cos its hard-coded to x32/x64. This is a problem.

Importing the libdir statement when building works, but you would need to have 2 install scripts (like before), due to the script being created depending on what is being built, and overwritten when building for another arch.

I dunno the best solution tho. Will see if there is any useful meson options to handle multi-arch builds and settings for this perhaps.

[shmerl]

May be Meson can configure standard names for 32-bit and 64-bit libdirs and use that to populate template placeholders in the setup script. And if you override some of them with --libdir, it will change that as well.

As long as generated scipt is always the same, it's OK to generate it twice and put in the same place. Weird things would happen if it's not the same and generated twice overwriting the first one.

[SveSop]

The problem is not standard names, cos in a way meson already uses that if not specified, and it seems distro related. Thats why on Ubuntu you end up with a libdir like x86_64-linux-gnu and i386-linux-gnu. However the latter is not used, cos you are not actually compiling under i386 when crosscompiling, so meson will just use x86_64-linux-gnu for both 32 and 64 bit lib/dll's. If you use chroot or other means of compiling under an ACTUAL i386 (32-bit) arch, it will be correct.

The problem is that we compile 2 times, and i dont know how to "import" other values, other than possibly reading some sort of variable from the "previous compile" or something.

Cross-compiling works like this atm:

1. Compile 64-bit cross-compile file: build-wine64.txt -> Uses variables to generate bin/setup_dxvk.sh.
2. Compile 32-bit cross-compile file: build-wine32.txt -> Uses variables to generate bin/setup_dxvk.sh (And overwrite the file).

The only way i can think of generating a setup script working for the settings used to compile the libs is to have meson build this after the others. Perhaps if the meson build would generate a file called "settings_$libarch" or some crap, and then the setup script could read that and use variables from that, such as $libdir and whatnot?

[shmerl]

Personally, I don't mind using my own custom setup_dxvk.sh like @doitsujin suggested before, and not touching the upstream one. This avoids all these complications and that's what Debian package for dxvk already does anyway (see here). But I think it's still useful to be able to make meson place dlls into libdir, instead of bindir. That's the minimal convenience improvement that can benefit customization.

So I guess this proposal was on point:

You have to add:
install_dir : get_option('libdir'),
to the meson.build files for d3d11, d3d10, dxgi , and then specify --libdir= like this:
meson --cross-file build-win64.txt --buildtype release --strip --libdir=lib64 --prefix $HOME/dxvk build.w64
meson --cross-file build-win32.txt --buildtype release --strip --libdir=lib32 --prefix $HOME/dxvk build.w32
That should put the dll's (and the .a files) in the --libdir= folder of your choosing.

If the --libdir= is not used, the "default" behavior is to the /bin folder. No need to introduce a new parameter. So i guess the easiest would be to set install_dir in the meson files, and not specify --libdir= when building to keep things as it is. So one would have the option to change if needed perhaps?

[shmerl]

I tested it though, and using that method while not specifying libdir places dlls in default libdir. So that's not the correct approach if we want to keep it backwards compatible to current behavior. It should have some conditional setting, not sure how though, since libdir is always defined I think.

I.e. the idea should be roughly:

if libdir not customized - use bindir.
otherwise, use libdir.

It's not clear how to check in Meson, if some parameter was set explicitly, vs being default.

[SveSop]

This is a problem with several solutions i guess.

1. What does the user want?
2. What do the package maintainer want?
3. What is actually possible to implement?

If several of those 3 options end up in the same result, it can be changed. So far, "we" are 2 users wanting the same option 1, but doing so will change stuff for option 2. I have not found something that give med my option 1, while keeping option 2 intact. Fiddling with the libdir statement will fiddle with the script. I dont think there is much will to change the script, as this could potentially change stuff for various distro's.

Not saying that will never happen, cos we see all the time changes being made that WILL force ppl to update stuff, but its all up to Philip and whatever reasoning he has with maintaining status quo.

So until then, i guess me personally I will have to stick with my patch script that i use each time a new pull is being made. (Fine for me really, cos i have a couple of other things i patch too, so no matter)

[shmerl]

That's why I'd prefer to find a backwards compatible solution, but I wouldn't mind if it's acceptable to simply place dlls into libdir to begin with. But it's a disruptive change as you said.

I asked about something like get_option_default('libdir') in Meson list, may be developers have some idea about that. If they don't have it, may be they can add such feature :)

[SveSop]

You can use meson_options.txt for this. Attached a patch that will change nothing when the current script is used (default /bin), but lets you set the install directory like this:
meson --cross-file build-win64.txt --buildtype release --prefix yourprefix --strip -Denable_tests=false -Dlib_dir=lib64 build.w64
If you do ninja install in the build.w64 folder, the .dll's will be placed in the "yourprefix/lib64" folder.
The -Dlib_dir= has 3 options: "bin" (default if not specified), "lib" (for 32-bit like wine does) or "lib64" (for 64-bit like wine does).

Does it help? The 3 options can be "whatever you like", but not "at the command line", as this is a settings file, and once the options is set those are your options.
https://mesonbuild.com/Build-options.html

If used, one can atleast customize more without the need to edit the individual meson.build files, and since the default is "as it is today", it should not be too intrusive?
meson_build.patch.gz

[shmerl]

I didn't quite get how setting that custom option lid_dir will place dlls into another location without changing meson.build files.

[SveSop]

The patch changes the meson.build files, but "if not specified" they wont change the current behavior.
What i meant was that you dont have to patch those files if you want to use your custom script or whatnot like it is now.

[shmerl]

Ah, got it. Then it's like my earlier proposal to introduce dlldir option above. Sure, that would take care of providing a customization while preserving current default.

I can make a PR for that if @doitsujin thinks it's a good approach.

I'd even make it simpler. Since it's not a standard option, you can simply check if it's empty (i.e. was not set) and then assign it a default (get_option('bindir')). Otherwise use the custom value.

Still, it would be useful for Meson to provide a way to programmatically check if something is default or not.

[SveSop]

Yeah. Today (dunno if its debian only), building manually without setting --libdir puts the dll's in the lib/x86_64-linux-gnu folder... specifying --libdir fixes this, but doing this like i did previously would fubar the installscript.

Doing it like i proposed in the patch atleast lets you choose this in a more sane manner :)

One can debate if the x32/x64 folder naming vs. the more system appropriate naming of lib/lib64 is the best tho? Maybe it even should be lib (64-bit) and lib32 (32-bit)? :)

I think meson keeps default values someplace you can print out. And the meson_options.txt have various things to set. The one i used with "type : combo" sets the default, and if its not specified it will use its default tho.

[shmerl]

I'd say better not to hardcode any naming in the option. Let the user set it explicitly if needed, and use current default (bindir) otherwise.

[SveSop]

Not sure what you mean by that? The meson_options.txt file kind of creates "aliases", and if its NOT created, the statement with get_option will throw an error.

[SveSop]

You cannot get_option('iamsexy') and expect to get a result :)

[shmerl]

I mean this seems to limit the values:

option('lib_dir', type : 'combo', choices : ['bin', 'lib', 'lib64'], value : 'bin')
My point is it's better not to assume any naming. Just check if dlldir is set, then use that as install_dir. Otherwise use bindir as it.

The reason it doesn't work with libdir is because it's always set. With custom option it would work.

[SveSop]

Afaik the meson_options.txt file does not take input from commandline, and i dunno if you can specify options from commandline that does not exist as an option.

To ask it differently: WHERE would the user "set" this option and how?

[shmerl]

You simply create a string option in meson_options.txt - dlldir that's empty by default. And then like I said above (i.e. you pass it as -Ddlldir=foo). That would do it.

[SveSop]

When do you set the value of that string option?

[shmerl]

When you call meson, using -Ddlldir.

[SveSop]

Absolutely a much better option @shmerl !
option('lib_dir', type : 'string', value : 'bin')
And it can be whatever you want :)

[shmerl]

I guess, if 'bin' is always guaranteed to be the value of bindir (which I'm not sure about). That's why I suggested not to assume values just to be safe :) I don't think you can reference something like get_option('bindir') in meson_options.txt unfortunately.

So this is the most flexible method:

option('dlldir', type : 'string', value : '')
And then check if it's empty (then set to get_option('bindir')) or not (leave as is) before using it as install_dir.

[SveSop]

Hmm.. what happens if the install_dir option is nothing?

[shmerl]

I didn't test it. May be it pushes it straight into the prefix dir in such case? But it wouldn't be a problem with the empty check like above.

[SveSop]

Its put directly in the build dir instead of /bin, so the script fails.
The script uses $PREFIX/install.64/bin "before fiddling with it". Setting install_dir : (nothing), puts the dll's directly in the $PREFIX/install.64 folder.

[SveSop]

I do think meson uses the default of "bin" for binary files when it comes to install_dir tho (when you set install : true option). But i cannot be sure if that is just "bin" or on other build systems it could be something else? I mean.. ubuntu have the default libdir = x86_64-linux-gnu, so for all i know the default COULD be something else.

But not specifying it at all seems to default to bin, so i dunno if its harmful to actually SET it to bin?

[SveSop]

I am not too familiar with the scripting system, but probably should be able to do some "if" statement to check if the get_option('lib_dir') is empty or not.

[shmerl]

I am not too familiar with the scripting system, but probably should be able to do some "if" statement to check if the get_option('lib_dir') is empty or not.

Yes, you can do that in meson.build for each dll in this case.

dlldir = get_option('dlldir')
if dlldir == ''
  dlldir = get_option('bindir')
endif
....
 install_dir: dlldir,
....

For a custom option it would work. Probably still better to use dlldir instead of lib_dir, since the later is too close to libdir which is the name of the pre-defined option.

[pchome]

I'm wondering, when you (people) need to compile almost everything, to be able to play games on your shiny CPU/GPU -- why don't you use gentoo? ;)

There is no problems w/ libdir.

[SveSop]

Yeah, but is it REALLY the "bindir" then? :) Not sure what the default install_dir actually is supposed to be, cos i found references saying:
install (added 0.50.0) When true, this generated file is installed during the install step, and install_dir must be set and not empty. When false, this generated file is not installed regardless of the value of install_dir. When omitted it defaults to true when install_dir is set and not empty, false otherwise.
https://github.com/mesonbuild/meson/blob/master/docs/markdown/Reference-manual.md
So.. install "when true" which it is (in the meson.build file for the dll's), then install_dir "must be set" (but is not currently). Is it the right behaviour?

@pchome Yeah, i wonder that sometimes too.. but im kinda bored with WoW theese days, and getting caught up in some minor problem solving when ppl as is.. well.. fun if i get it working, and crap when i dont.

I have no problems with my compile, but when the person asks, i try to help :)

The question is: How can one add a custom option to put the binaries into user-selected folder without fucking up ppls expected behaviour of the current scripts too much? :)

PS. Talking about wasting time: The amount of time i have spent trying to get winelib working with WoW, i would have had 10 characters with 390 ilvl by now hehe.. But it would be more rewarding getting that to work over having those characters i guess...

PPS. And the worst part is.. i dont even use DXVK for WoW anymore...

[shmerl]

So.. install "when true" which it is (in the meson.build file for the dll's), then install_dir "must be set" (but is not currently). Is it the right behaviour?

I'm not sure why exactly, but dlls now always end up in bindir by default. So the above approach will preserve that exactly, unless user will override dlldir with -Ddlldir=foo. I.e. install_dir will never be empty.

why don't you use gentoo

Some balance I suppose? Some like super optimized packages in Gentoo, but I'm OK with more automated Debian really. Stuff like dxvk on the other hand is rather new, so approaches to install and use it aren't yet very established, so I have no problem with manually building it.

The question is: How can one add a custom option to put the binaries into user-selected folder without fucking up ppls expected behaviour of the current scripts too much

Yep, exactly. @doitsujin pointed out, he doesn't want to disrupt the current workflow, thus the whole discussion how to fit that in.

[pchome]

@SveSop

The question is: How can one add a custom option to put the binaries into user-selected folder without fucking up ppls expected behaviour of the current scripts too much? :)

Use custom cross-file, name it build-mydistro-win.txt, and set required parameters there.

[shmerl]

Use custom cross-file, name it build-mydistro-win.txt, and set required parameters there.

Doable, but more messy than simply adding -D to meson invocation. Plus requires syncing it with upstream cross files if they change.

[Joshua-Ashton]

Weren't you already told that this wasn't intended for your use?

If you're a package maintainer, you should do your job and maintain your packages instead of trying to get your specific stuff into upstream when its not relevant to anything else.

[shmerl]

Weren't you already told that this wasn't intended for your use?

I'm not using default setup_dxvk.sh as @doitsujin suggested, so that doesn't bother me, I already explained above. It's only about location for dlls.

What's the problem with upstream being flexible about it? There is no reason to place it in bin to begin with, besides just de-facto way meson is doing it. So it wouldn't hurt making that configurable, keeping the default as is.

[SveSop]

Weren't you already told that this wasn't intended for your use?

If you're a package maintainer, you should do your job and maintain your packages instead of trying to get your specific stuff into upstream when its not relevant to anything else.

One could argue if placing dll's or dll.so's in x32/x64 folders is particularly correct (and even doing it by bash script). Then again, that is up to the package maintainer as you say. These scripts is for "everybody else" really, as a package maintainer would probably do this in totally different ways anyway.

Can one expect "package maintainers" to use the package-release.sh script? Probably not. Can one expect package maintainers to use the included build-win*.txt scripts? Probably not. Then who uses it? "Everybody else" :) And being one of those "everybody else" i would like another option... and who knows, maybe it can help somebody else :)

But saying "this is a useless idea, we see no usage for at all" is fair enough. 👍

[Thaodan]

I think a beter way would be separating the script from the libs (packaging wise) and adding the option to use a different $libdir or $prefix at run time.
With that something like --libdir would be enough.

Its true that package maintainer will change things if needed. But I don't think its a good way that its require it for packagers to make their own changes on the build system or setup scripts.

Fixing the setup script to support a custom $libdir or $prefix would be enough.

[shmerl]

Yeah, that was my original thought, to make it all more flexible, to support different use cases. But @doitsujin suggested not to bother with customizing upstream setup_dxvk.sh and just create one with whatever logic outside. That's what Debian maintainer did in the end as well.

So I followed that idea, but still wanted to make it possible to control where dlls are placed. You already can control libdir and prefix during build now, so that's not the issue. Only dlls are outliers, since they are just point blank placed in bindir now.

[SveSop]

There is usually no need to specify install paths or the like. Meson will automatically install it to the standards-conforming location. In this particular case the executable is installed to the bin subdirectory of the install prefix. However if you wish to override the install dir, you can do that with the install_dir argument.
https://mesonbuild.com/Installing.html

Having a more "inline with meson way" to create your own custom build script, that uses the statement install_dir vs. libdir have to be a better solution imo.

[shmerl]

Proposed approach is doing that, providing install_dir for each dll accordingly. This should only affect dlls, so not sure how you can do that without modifying meson.build files.

[SveSop]

Kinda what i am saying @shmerl .. i just quoted the meson handbook to say it :)

[doitsujin]

Should no longer be relevant due to the changes in 1.0.