Arch Linux User Repository

I've noticed in some cases that the symlink to the system's rapidjson can sometimes not clean up correctly, causing the build to fail in the prepare step trying to make another symlink. I've added a guard around the ln so that it'll only create it if it doesn't exist. Thought it might help, let me know what you think!

diff --git a/PKGBUILD b/PKGBUILD
index 18bb5dc..ecb271f 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -31,7 +31,9 @@ prepare() {
   cd "$srcdir/$pkgname"
   ln -sf "$srcdir/discord-rpc" discord-rpc
   mkdir -p discord-rpc/thirdparty
-  ln -sf "/usr/include/rapidjson" discord-rpc/thirdparty/rapidjson
+  if [[ ! -L "$srcdir/discord-rpc/thirdparty/rapidjson" ]]; then
+    ln -sf "/usr/include/rapidjson" discord-rpc/thirdparty/rapidjson
+  fi
 }

 build() {

Could you base the pkgver on latest tag + commits since then?

That would most likely need to be supported in our cmakelists.txt, I have only added support for building discord-rpc from source. Feel free to file an issue for that, or better yet, submit a PR.

thanks. Discord-rpc is also shared and maybe possible as an optdepend.

@JudgeManganese: I haven't managed to reproduce that, including when building inside a fresh chroot.

@Thaodan: sure, done.

Can we build with distro rapidjson instead of the shared one?

The objects/title sequences that CMake downloads as part of package() are now causing the PKGBUILD to fail with the below error. CMake is showing the hash for an empty file because the file wasn't downloaded. It seems makepkg is not allowing CMake to download because I can manually run the commands in package() and they get downloaded.

CMake Error at cmake_install.cmake:48 (file):
  file DOWNLOAD HASH mismatch

    for file: [<path-to-cache>/openrct2-git/pkg/openrct2-git/usr/share/openrct2/title/title-sequences.zip]
      expected hash: [1136ef92bfb05cd1cba9831ba6dc4a653d87a246]
        actual hash: [da39a3ee5e6b4b0d3255bfef95601890afd80709]
             status: [6;"Couldn't resolve host name"]

hmm, it's maybe not so simple - I think the tests might expect those files to be in /, rather than inside $DESTDIR...

maybe it's easiest just to disable the tests for now.

Ah, good catch!

I'll make it download the objects/title sequences in advance. I've never been very happy with the fact that cmake downloads them (and most distros don't allow this in their policy, as it breaks reproducibility of the build process if the files ever disappear from the net).

I guess another option is that the cmake config should be fixed such that the test target depends on the target that downloads the objects.

check() runs tests, but they need files that get download upon installation with install target, which only gets done in package() after successful check().

The options to address that that I can think of right now include: 1. perform install target in check(), before running tests 2. run tests in package() 3. pre-populate required files as part of PKGBUILD 4. use ctest to split running the some tests in check(), some in package()

Other suggestions welcome.