Package Base Details: vulkan-caps-viewer

Git Clone URL: https://aur.archlinux.org/vulkan-caps-viewer.git (read-only, click to copy)
Submitter: yochananmarqos
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 46
Popularity: 0.032187
First Submitted: 2024-03-05 22:44 (UTC)
Last Updated: 2024-03-31 18:18 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

yochananmarqos commented on 2020-05-31 14:30 (UTC)

Is this segfaulting for anyone else?

libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Segmentation fault (core dumped)

Freso commented on 2020-05-17 10:34 (UTC)

what is needed for building and for running are two independent sets, you can't ignore things in one because they're in the other

Yes, you can. You don’t need to specify things in $makedepends if they’re in $depends. Note that $makedepends is defined as "An array of packages that are only required to build the software." while $depends is "An array of packages that must be installed for the software to build and run." Thus, if something belongs in $depends it does, by definition, not belong in $makedepends.

thrimbor commented on 2020-05-17 03:33 (UTC)

The last update reduced the version number instead of increasing it (from 2.03-2 to 2.03a-2, the former being considered newer by vercmp). Please fix this, as it confuses several tools that rely on proper versioning.

Althorion commented on 2020-05-09 13:23 (UTC) (edited on 2020-05-09 13:23 (UTC) by Althorion)

@1ace as per Arch package guidelines, even configure belongs to the build() (look at the prototype). The CMake package guidelines also put it in the build() phase.

1ace commented on 2020-05-07 21:34 (UTC)

@yochananmarqos: I wasn't keen on making the package download the whole git repository just so that I could use git submodules, but since the latest vulkan-headers update removed symbols that vulkan-caps-viewer used, I've had to so that the build would use a pinned version of the headers, and I now use the submodule solution you suggested :)

As for qmake, it's a configuration tool, just like cmake; it belongs in prepare().

yochananmarqos commented on 2020-04-15 23:30 (UTC) (edited on 2020-04-15 23:30 (UTC) by yochananmarqos)

HACK: github doesn't package submodules...

No need for a "hack", see VCS package guidelines:

prepare() {
  cd '$pkgname-$pkgver"
  git submodule init
  git config submodule.Vulkan-Headers.url "$srcdir/Vulkan-Headers"
  git submodule update
}

I've also updated my PKGBUILD.

yochananmarqos commented on 2019-11-29 15:29 (UTC) (edited on 2020-04-15 23:15 (UTC) by yochananmarqos)

@1ace: You're using qmake in prepare(), that's a build function.

1ace commented on 2019-11-29 11:55 (UTC)

@yochananmarqos:

Well, what about vulkan-headers-git then?

there's no way to know if the user's build of that package would be recent enough, making it entirely unusable for this situation.

If the package requires qt5-base then there's no need for it to be in makedepends.

what is needed for building and for running are two independent sets, you can't ignore things in one because they're in the other

Building needs to be in the build() array, not in prepare().

this package is not building anything in prepare(), I'm not sure what you mean?

Here's an improved PKGBUILD [...]

most of your changes are not actually doing anything, but I did move the git clone/fetching to makepkg, which will avoid the full clone when doing a clean build from an already-used PKGBUILD :)

yochananmarqos commented on 2019-10-08 23:50 (UTC) (edited on 2019-11-29 15:23 (UTC) by yochananmarqos)

Well, what about vulkan-headers-git then?

If the package requires qt5-base then there's no need for it to be in makedepends.

Building needs to be in the build() array, not in prepare().

1ace commented on 2019-10-08 23:08 (UTC) (edited on 2019-10-08 23:08 (UTC) by 1ace)

No, the point is precisely to use the latest headers, regardless of what is currently shipped in the arch package.