Arch Linux User Repository

Just a few notes: the reshade source is unnecessary, everything has been moved into the main repo and the dependency on vulkan-tools isn't needed

This isn't supposed to be a dev package, so I didn't want to update it again till a release came about, but it seems it doesn't build anymore, probably because of GCC 10, so might as well.

Thank you @frankyboy for giving me a summary of the changes and saving me the time!

I have not tried the 32b version yet or even the 64b extensively, so please tell me if I made a mistake somewhere.

https://github.com/DadSchoorse/vkBasalt/pull/81

build type changed to meson :) Also includes the shaders in the binary so a shader directory isn't needed anymore.

@I'm happy this work for you now @bajczyk, but please remember the real heros are the ones writing the code to make it work/build, not the ones doing the simple PKGBUILD stuff. :)

Hi guys, I just want to thank you for this work, you're awesome :D it compiles now, so thanks to you I can finally enjoy image sharpening!

@yochananmarqos It's all good.

Well, I didn't want to force the newer dev version onto people that had a fine stable build, that's why I didn't do what you're suggesting. But maybe I shouldn't worry too much about that and let people ignore this or not as they want.

As for reshade, that's cool, it was annoying and error-prone to do it manually thank you!

@gee: Ha, I commented without even looking at the changes. Sorry, my mind is on other things.

What you did of course is what I was talking about. However, since its a release tag + a commit after, add a pkgver() function:

pkgver() {
  cd ${srcdir}/vkBasalt
  git describe --tags | sed 's/^v//;s/-/+/g'
}

0.3.1+12+g5b4ce45

You don't have to specify a commit for reshade since it's a nested submodule. It will automatically pull the right commit.

Hooray, it builds!

@yochananmarqos wow that was super quick! Well that's kind of what I did, but I didn't want to force people with a working build to now use a dev one, in case there are issues. Not sure if the releases are actually tested and supposed to be more stable that your everyday commit though.

What do you think?

Thank you very much!

@gee You can still maintain this package as a "stable" release, but use a specific commit instead of the release tarball. See the gtk3 package for an example.

I grabbed your change bpierre since it's the 2nd time you mention this, but it won't fix any problem with building, and all you need to do to see the actual error is scroll up. I think you should start that discussion upstream though. :)

As for the build break, that's the joy of using a bleeding edge distribution. I switched to a newer commit that builds fine, but now the version is lying... It'd be cleaner to switch to a git package but it'd also be annoying to go back and forth the two as one works and not the other. I didn't want to increment the version because for people that already have it built, they shouldn't change anything. I hope that's acceptable for now.