Arch Linux User Repository

I don't think it is caused by the missing double quotes because it is pretty uncommon to build packages in a path that needs to be quoted (though quotes should still be added for those uncommon scenarios).

The actual problem here is that $pkgdir contains an absolute path so there is no need to add ${_pkgbasename}-${pkgver}/ before it.

-  rm -rf "$pkgdir"/usr/{include,share,bin}
+  rm -rf ${_pkgbasename}-${pkgver}/${pkgdir}/usr/{include,share,bin}

Pretty obvious issue here, I'd think. Deleting the quotes around the pkgdir variable was pretty astonishing, too.

I had no problem installing this package (just to be sure, I always use pacaur to install my own package once it has been submitted).

You claim that you used pacaur to install the published version, however, the published version cannot under any circumstances have deleted those files properly. And I cannot imagine how the CMakeLists.txt could fail to install them.

So you're either misremembering or lying that you double-checked with pacaur, or else (this is a wild guess, but pacaur does dumb things all the time, so maybe) pacaur did something stupid like reuse a cached .pkg.tar which you built with makepkg using a different PKGBUILD than the one you published, which would mean your check was a waste of time to begin with. Do you remember if pacaur actually showed build output? Do you use pacaur with the idiotic --silent flag (see above under "pacaur does dumb things")?

I do, however, have a small tip for you. Don't use the -f flag to rm. It's bad and does bad things. If your rm command is completely broken and does something totally wrong, trying to delete files that cannot possibly exist, then -f causes it to ignore errors. Ignoring errors is bad. Using rm -f in a PKGBUILD is like using make || true. It's possible you might have a good reason to do it, but that's rarely the case.

Using rm -r without -f would cause that to fail during package() instead of failing due to pacman file conflicts.

@thaewrapt please, don't flag a package as being out-of-date because there is a comment about a bug. Moreover, the comment was sent earlier today, give some time to address the issue. Out-of-date flag is to be used when the source changes. Otherwise, add a comment or use "Submit a request"

About @Nocifer's comment, I had no problem installing this package (just to be sure, I always use pacaur to install my own package once it has been submitted). While the include, share and bin folders are supposed to be deleted when packaging, the installation folder changed in the last update to mirror the arch package and I may not have deleted the folders properly. I'll investigate the problem later or in the next few days (I have other things on the back burner for now).

Latest update causes this to break because of conflicting files with shaderc:

error: failed to commit transaction (conflicting files)
lib32-shaderc: /usr/bin/glslc exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/env.h exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/shaderc.h exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/shaderc.hpp exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/status.h exists in filesystem (owned by shaderc)
lib32-shaderc: /usr/include/shaderc/visibility.h exists in filesystem (owned by shaderc)
Errors occurred, no packages were upgraded.

Sorry, I've been busy with not much time to work on this. Fixed lib32-glslang first.

You should receive a new version (2019.0-2) soon. If you encounter an error, you may have to clean your lib32-shaderc folder.

The latest glslang package just made this package broken.

Please add the patch from the 64-bit version in [extra]: https://git.archlinux.org/svntogit/packages.git/tree/trunk/shaderc-2019.0-fix-build-against-new-glslang.patch?h=packages/shaderc

And add export CXXFLAGS+=" -I/usr/include/glslang" in build()

(According to the commit from the 64-bit version: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/shaderc&id=72283b634a0bd7c8d99cc605e273fe1294b77b44)

@tjackson : please, add the full linking error if you are still experiencing this problem.

I'm still seeing the undefined reference to glslang::TProgram::... QuartzDragon mentioned. I had to downgrade lib32-glslang to 7.11.3214 and it went away.