Package Details: gzdoom 4.12.2-1

Git Clone URL: https://aur.archlinux.org/gzdoom.git (read-only, click to copy)
Package Base: gzdoom
Description: Feature centric port for all Doom engine games
Upstream URL: http://www.zdoom.org/
Licenses: GPL3, BSD, LGPL3
Replaces: gzdoom-legacy, gzdoom1
Submitter: None
Maintainer: grubber
Last Packager: grubber
Votes: 156
Popularity: 1.50
First Submitted: 2009-02-22 22:28 (UTC)
Last Updated: 2024-05-17 07:47 (UTC)

Dependencies (27)

Sources (3)

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 Next › Last »

grubber commented on 2016-12-14 17:20 (UTC)

Why by default? You can easily disable it yourself in the PKGBUILD.

Flisk commented on 2016-11-25 00:33 (UTC)

Are there any reasons not to disable fmodex by default? I'm currently getting segfaults when discovering secrets on fmodex-enabled builds, and the problem goes away when I build without fmod. Am I alone with that issue?

allcaps commented on 2016-03-05 08:13 (UTC) (edited on 2016-03-05 08:13 (UTC) by allcaps)

The fmodex version this requires is not available by the standard fmodex AUR entry. There's one named differently here: https://aur.archlinux.org/packages/fmodex4.26.36 that is the exact version needed. If you replace the fmodex entry at the top of the pkgbuild with that one instead this builds and works fine, sound and all.

zan commented on 2016-03-04 02:08 (UTC) (edited on 2016-03-04 02:09 (UTC) by zan)

Note that kdialog replaces gxmessage (it is the kde xmessage implementation), so only one or the other is required.

grubber commented on 2016-03-03 21:07 (UTC)

Fmodex can't be an optdepend - optdepends are for *runtime* optional dependencies, but fmodex is a *build-time* optional dependency - if you build the package with fmodex, the gzdoom binary will be linked to libfmodex, so uninstalling it would break the binary, which is not correct. You can choose whether to build with or without fmodex using the _fmodex variable at the top of the PKGBUILD, ditto for openal. There is no harm in defining SHARE_DIR in CFLAGS and it keeps CFLAGS consistent with CXXFLAGS. The SHARE_DIR patch is there to support the IWAD symlinks included in the package, which are there so you can put retail IWADs to your user IWAD directory without hiding IWADs of the same name provided by the freedoom and hexen1-wad packages. I suppose putting the symlinks into the libdir should work equally well, which would obsolete the patch. Didn't know about kdialog, will fix.

zan commented on 2016-03-03 15:01 (UTC)

Some observations after having maintained the alternate 2.1 while waiting for the update: fmod and openal are technically optional, but without either you have no sound. Since openal is in the upstream official repos while fmod is not, I'd advocate making fmod an optdepend. You don't need to specify SHARE_DIR on cflags, it is only used on cxxflags. I'd also argue the patch to include SHARE_DIR in the iwad search path is unnecessary - you are supposed to install the main game iwads either with pacman in /usr/local?/share/games?/doom - every AUR package for an iwad uses /usr/share/doom. The extra files gzdoom uses are not iwads, they just need to be on the file search path which is what SHARE_DIR is for in the first place. Also, kdebase-kdialog is an optdepend and gzdoom will use it for its launcher if available over the gtk alternative, which should also probably be an optdepend.

grubber commented on 2016-03-03 07:05 (UTC)

Updated. Sorry for the delay - I rewrote the PKGBUILD, OpenAL is now supported, among other improvements and fixes.

<deleted-account> commented on 2016-02-19 03:59 (UTC)

http://debian.drdteam.org/pool/multiverse/g/ gzdoom gzdoom1

zan commented on 2016-02-18 00:17 (UTC)

Wanted to install 2.1 on several computers so I just forked the pkg and dropped the patches here: https://aur.archlinux.org/packages/gzdoom-2.1/ I have notifications on so I'll delete it whenever grubber updates here.

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 Next › Last »