Package Details: gzdoom-git 4.15pre+487+gf30fc8d-2

Git Clone URL: https://aur.archlinux.org/gzdoom-git.git (read-only, click to copy)
Package Base: gzdoom-git
Description: Feature centric port for all Doom engine games (git version)
Upstream URL: http://www.zdoom.org/
Licenses: GPL3, BSD, LGPL3
Conflicts: gzdoom
Provides: gzdoom
Replaces: gzdoom-legacy-git, gzdoom1-git
Submitter: grubber
Maintainer: MaddieMewmews
Last Packager: MaddieMewmews
Votes: 24
Popularity: 0.000617
First Submitted: 2013-06-25 15:27 (UTC)
Last Updated: 2025-08-13 23:06 (UTC)

Dependencies (29)

Required by (10)

Sources (2)

Latest Comments

1 2 3 4 5 6 7 Next › Last »

kinker31 commented on 2025-10-04 06:51 (UTC) (edited on 2025-10-04 07:26 (UTC) by kinker31)

Okay, I think I might've been able to single out the problem a bit: Somewhere within the CMake generation process, instead of one of the lines being [PKGBUILD]/src/gzdoom/libraries/ZMusic/include/ as it should, it literally turns into [PKGBUILD]src/gzdoom/src/../include/zmusic.h, which doesn't translate into a readable directory.

I think we should be good once that gets figured out?

EDIT: I did the following workaround: First, I removed the external ZMusic library, which didn't work at first. Upon finding where zmusic.h was located, I then proceeded to locate the file where the infamous error I'd been having was, then proceeded to manually patch the file while the package was building to make sure it actually pointed to where it needed to be.

This is a very terrible idea, but the package installs properly that way.

kinker31 commented on 2025-09-26 09:41 (UTC)

I've been lately getting this when getting to the package() step:

CMake Error at src/cmake_install.cmake:73 (file):
  file INSTALL cannot find
  "/home/kinker31/.cache/paru/clone/gzdoom-git/src/gzdoom/src/../include/zmusic.h":
  No such file or directory.
Call Stack (most recent call first):
  cmake_install.cmake:116 (include)

Perhaps a file wasn't copied over during an earlier step?

MaddieMewmews commented on 2025-08-13 22:58 (UTC)

Fixed CPPDAP conflicts (turns out the library isn't actually a dependency, so nuking the files from the pkg folder works), also ZMusic and ZWidget are handled correctly now (I have NO idea what upstream wants to do at this point)

ipaqmaster commented on 2025-08-10 22:41 (UTC)

I too am experiencing extra/cppdap file conflicts during my latest system update.

architector4 commented on 2025-08-09 15:58 (UTC)

Can confirm on my end. I have git set up, so instead it asks me to write a commit message for a merge lol

parkerlreed commented on 2025-08-08 18:47 (UTC)

Some weirdness with the submodules

==> Starting prepare()...
From /build/gzdoom-git/src/ZMusic
 * branch                  master     -> FETCH_HEAD
Subtree is already at commit ac3e232b001129c740b7b65196ae0e1b13b82513.
From /build/gzdoom-git/src/ZWidget
 * branch                  master     -> FETCH_HEAD
Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'builduser@arch-nspawn-55336.(none)')

MarisaDOOM commented on 2025-08-06 16:47 (UTC)

The woes continue, now there are file conflicts with the cppdap package since gzdoom is bundling its own version of it. the package is a dependency of cmake, so it's needed to build this whole thing.

MaddieMewmews commented on 2025-08-04 22:01 (UTC)

Quick little update, ZMusic is now included upstream, so I just implemented their handling of it as a subtree, and I added a manual bypass commented out for format-security errors because upstream keeps breaking. (Do note that due to a current cmake bug ZMusic will still detect a system-level ZMusic library even if FORCE_INTERNAL_ZMUSIC is manually set, this will get fixed if my PR gets merged https://github.com/ZDoom/gzdoom/pull/3286 )

MarisaDOOM commented on 2025-08-04 10:06 (UTC)

Since e5f42ab ZMusic is now included as a submodule, so it's probably fair to remove it from the dependencies (or make it optional?).