"dlls_setup.sh" not executable and with too generic a name about dxvk HOT 18 CLOSED

Resolved in 8f134ba.

As for packaging, the setup scripts are required to be in the same location as the DLLs so that they can be used for downloadable binary releases as well. It is however possible to create symlinks to the scripts in /usr/bin if you absolutely want to do that.

from dxvk.

I think @doitsujin meant that since you have to symlink it anyway, you can name it whatever you please (e.g. dxvk_setup -> /usr/lib64/dxvk/setup_dxvk.sh and dxvk_setup32 -> /usr/lib/dxvk/setup_dxvk.sh)

from dxvk.

I second the name change. I'm not familiar with mason either though, I'm not sure which is the proper way to fix permissions.

from dxvk.

Also note that the script only sets the dlls for the build that generates it, so you need one for 32 and one for 64 bit or to merge them together. Specifically, the dlls redirection is common but the PATH environment modification is not, as it have to point to the proper architecture.

from dxvk.

I think a good name would be setup_dxvk.sh.

On a related note, the script currently hardcodes the path where the DLLs are installed, which causes trouble with any sort of binary release (as you probably have noticed). I considered changing it to $PWD but that is not an optimal solution either. Any thoughts on this?

from dxvk.

I didn't used $PWD because it would mess things up if the script is not used in its folder. Packaging is no easy matter in my opinion, for example having the setup script in the same folder of dlls not what I'd expect in a package (windows dlls and executables shouldn't be in bin folder the same as the linux bash script). I was thinking about adding an meson option to change the hardcoded path to dlls, that would be quite clean and easy for packagers who want to have separate bin and dlls folders.

from dxvk.

The thing with binary releases in general is that people should not be forced to put them into a specific directory, so the script must determine the install path at runtime anyway. $PWD is bad, but better than what we have now, and checking whether the two DLLs exist within the given directory is trivial.

Alternatively we could allow/force users to specify the full path as a command line argument as well, but then have to make sure that the path is absolute.

from dxvk.

Alternatively we could allow/force users to specify the full path as a command line argument as well, but then have to make sure that the path is absolute.

I though about that, but since wine is used by any kind of user I'd keep it as simple as possible.
Sadly, packaging is a nasty task: if you want to give packagers absolute freedom (allow them to place the script in a different directory than dlls) and to allow it to be specified at runtime common ways are:

• Environment variable (but it's not a clean solution)
• Config file (kinda an overkill atm, and you have to find it also, so it's just moving the problem)
• User specify the path

I think that an option at build time would be preferable, packagers can build the package hardcodeing the correct directory (paths don't change after packing after all). For example I'm currently using --prefix=/opt/dxvk/ and --prefix=/opt/dxvk32/ for my installation and the script gets configured for these, it's should be easy to add a build option to override the hardcoded path (easier than set the executable privilege probably XD).

from dxvk.

It would also be neat if the 32 and 64 bit builds could be installed in the same prefix (with x32 and x64 subfolders for the dlls, maybe?) and then the same script could be used to:

• Replace the 32 bit dlls from a 32-bit WINEPREFIX
• Replace both the 32 and 64 bit dlls from a 64-bit WINEPREFIX
• (maybe? unsure of its usefulness) replace only the 32 bit or 64 bit dlls from a 64-bit WINEPREFIX

I think this would make maintenance and packaging easier. 64-bit only distros (like Arch) could include everything in a single package, and distros supporting 32-bit, like Debian, could split it into 3 packages ("dxvk-dlls", architecture-specific with both amd64 and i386 versions, containing the dlls, and "dxvk-common", with the architecture-independent files, like the script; this layout is common to most packages, even wine itself).

My PKGBUILD currently only builds and installs the 64-bit dlls, I need to figure out the best way to include the 32-bit ones as well.

Alternatively, the script could be forced to be kept with the dlls and then make the packagers symlink somewhere into the PATH...

from dxvk.

Distributions differ very much in 32 and 64 bit libs paths, and with these being dlls and not linux libs the matter is even more complex. I'd rather create a template script with easy to edit path for packages to replace with their own.

from dxvk.

Maybe avoid the entire path issue by packaging the entire binary distribution into the bash script, e.g. https://stackoverflow.com/a/955472

A few days ago I googled it and you can autodetect if it's a 32 bit or 64 bit wine prefix:

WINESYSDIR=$( winepath -u c:\\windows\\system32 2> /dev/null )
if [[ ${WINESYSDIR} == *"/system32" ]]; then
  echo "Registering 32 bit libs in 32 bit prefix"
  ...
fi
if [[ ${WINESYSDIR} == *"/syswow64"* ]]; then
  echo "Registering 32 bit and 64 bit libs in 64 bit prefix"
  ...
fi

from dxvk.

Detecting the wineprefix architecture is not an issue, you can add both 32 and 64 bit dlls to a 32 bit wineprefix the 64 bit dlls will just be ignored (note that the script doesn't copy anything into system32 or syswow64, it just add dlls directories to windows' PATH, that way it's easier to set and revert it)

from dxvk.

Would it not be easier form a packaging standpoint to have it install dlls and configure for within the prefix via winetricks?
If we set up a build server for the latest git version, then have a winetricks script fetch form a url and do it's magic.

from dxvk.

That wouldn't be "packing" as it would be hard to keep it updated properly. Winetricks is used for windows libs which do not get updated every a few days.

from dxvk.

That's just what I've done for the AUR package.
Now it installs both the 32 and 64 bit versions, under /usr/local/dxvk/[w32,w64], and I symlink each setup script to /usr/local/bin as setup_dxvk32 and setup_dxvk64, respectively.

But I agree with Raffarti that maybe the name would be better as "dxvk_setup" rather than "setup_dxvk", easier to find and for autocomplete.

from dxvk.

really local?
please read:
https://wiki.archlinux.org/index.php/MinGW_package_guidelines#Packaging

from dxvk.

@Thaodan
If you want to discuss about my packaging choices, I think it'd be better to do so in the package's AUR page:
https://aur.archlinux.org/packages/dxvk-git/

Having said that... dxvk is not a package for a mingw64 cross-compiling environment, so I don't see how would what you link to apply.

from dxvk.

ok, but anyway /usr/local is not for pkgs.

from dxvk.