[Request] vcmi

[slepice24]

Package:

vcmi - https://aur.archlinux.org/packages/vcmi Manual Installation - https://wiki.vcmi.eu/How_to_build_VCMI_(Linux)

Purpose:

recreation of heroes III engine that brings new features

Benefits:

No response

Building:

optional dependencies are required for vcmibuilder (at least unshield)

Copyright:

VCMI source code is licensed under GPL2, vcmi-assets - https://github.com/vcmi/vcmi-assets

Expected Interest:

some

Already available?

no

Unique request?

yes

Banned package?

no

More information:

No response

[xiota]

Suppose vcmi and vcmi-assets are both made available. Will the game work? Or is access to the original game still somehow required?

[slepice24]

Suppose vcmi and vcmi-assets are both made available. Will the game work? Or is access to the original game still somehow required?

you need the original game files to play

[xiota]

you need the original game files to play

If it's not at all usable without proprietary data, I'm inclined against adding, but another maintainer may have a different opinion.

[slepice24]

you need the original game files to play

sorry i wast detail, for installation and runing vcmi you dont need heroes III but for playing you need it, sorry any confusion made

[xiota]

Why would anyone run it if it can't be played?

[slepice24]

Why would anyone run it if it can't be played?

importing game files

[Technetium1]

I'm happy we can provide resources when necessary, sometimes it's painful to build and/or download some sources for various reasons. The only issue we can have is when the lack of one of those 'proprietary files' prevents building. That's the issue we have with ezquake, which we would otherwise be fine to redistribute. If it builds without needing extra files, and the size is reasonable, then it's okay. In this case, everything comes from GitHub & the Arch repos except fuzzylite.

I tried to build it to see the size, and it's at least >100MB. It also doesn't build in a clean chroot due to missing dependencies. Due to the size and build failure in a clean chroot, this request is unfortunately rejected.

If you'd like to report this not building in a clean chroot to the maintainer, so it can be fixed, it would help others. One clear problem is minizip missing in makedepends.

Failed Build Log

-- Checking for module 'minizip'
--   Package 'minizip', required by 'virtual:world', not found
-- Could NOT find minizip (missing: minizip_LIBRARY minizip_INCLUDE_DIR)
-- Found SDL2: /usr/lib/libSDL2.so (found version "2.28.3")
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (SDL2main)
  does not match the name of the calling package (SDL2).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake_modules/FindSDL2.cmake:318 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:410 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found SDL2main: /usr/lib/libSDL2main.a (found version "2.28.3")
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (SDL2main)
  does not match the name of the calling package (SDL2).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake_modules/FindSDL2.cmake:318 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  cmake_modules/FindSDL2_image.cmake:114 (find_package)
  CMakeLists.txt:411 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found SDL2_image: /usr/lib/libSDL2_image.so (found version "2.6.3")
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (SDL2main)
  does not match the name of the calling package (SDL2).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake_modules/FindSDL2.cmake:318 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  cmake_modules/FindSDL2_mixer.cmake:112 (find_package)
  CMakeLists.txt:415 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found SDL2_mixer: /usr/lib/libSDL2_mixer.so (found version "2.6.3")
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (SDL2main)
  does not match the name of the calling package (SDL2).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake_modules/FindSDL2.cmake:318 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  cmake_modules/FindSDL2_ttf.cmake:114 (find_package)
  CMakeLists.txt:419 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found SDL2_ttf: /usr/lib/libSDL2_ttf.so (found version "2.20.2")
CMake Error at /usr/lib/cmake/Qt5/Qt5Config.cmake:28 (find_package):
  Could not find a package configuration file provided by "Qt5LinguistTools"
  with any of the following names:

    Qt5LinguistToolsConfig.cmake
    qt5linguisttools-config.cmake

  Add the installation prefix of "Qt5LinguistTools" to CMAKE_PREFIX_PATH or
  set "Qt5LinguistTools_DIR" to a directory containing one of the above
  files.  If "Qt5LinguistTools" provides a separate development package or
  SDK, be sure it has been installed.
Call Stack (most recent call first):
  CMakeLists.txt:430 (find_package)


-- Configuring incomplete, errors occurred!
==> ERROR: A failure occurred in build().
    Aborting...

[xiota]

Reopening for re-review because someone requested in chat.

Looks like maintainer is active. PKGBUILD could be improved, but don't think they're showstoppers (mkdir, ccache). So if size is okay and it builds/works (or maintainer fixes issues), I'd have no problem with adding it.

[xiota]

Update: Fails to build.

In file included from /home/builder/build/src/vcmi-git/client/renderSDL/CTrueTypeFont.cpp:23:
/usr/include/SDL2/SDL_ttf.h:165:16: error: using typedef-name ‘using TTF_Font = struct _TTF_Font’ after ‘struct’
  165 | typedef struct TTF_Font TTF_Font;
      |                ^~~~~~~~
In file included from /home/builder/build/src/vcmi-git/client/renderSDL/CTrueTypeFont.cpp:11:
/home/builder/build/src/vcmi-git/client/renderSDL/CTrueTypeFont.h:20:7: note: ‘using TTF_Font = struct _TTF_Font’ has a previous declaration here
   20 | using TTF_Font = struct _TTF_Font;
      |       ^~~~~~~~
/usr/include/SDL2/SDL_ttf.h:165:25: error: conflicting declaration ‘typedef int TTF_Font’
  165 | typedef struct TTF_Font TTF_Font;
      |                         ^~~~~~~~
/home/builder/build/src/vcmi-git/client/renderSDL/CTrueTypeFont.h:20:7: note: previous declaration as ‘using TTF_Font = struct _TTF_Font’
   20 | using TTF_Font = struct _TTF_Font;
      |       ^~~~~~~~

[xiota]

Added with interfere. Lots of minor adjustments, but collectively not minor.

[Gigas002]

I found out this is now included in chaotic-aur, a bit late though. @xiota would you like me to introduce some changes from your work into PKGBUILD? I can see you've changed the build system to ninja instead of make. I am not familiar with it, will it benefit build times?

[xiota]

@Gigas002 I think the PKGBUILD would be better if all of the changes are adopted, though not exactly as they appear in the interfere. I didn't propose them on aurweb because many of the changes don't affect the final package. Some may be considered personal preference or low priority.

Explanation also takes a while. But since you've indicated interest...

• Ninja automagically parallelizes tasks and produces more understandable error messages than Make. Whether to use it is up to the maintainer, and I wouldn't normally add an interfere just for Ninja. In this case, Ninja was bundled with other changes.

• Packages shouldn't use ccache. This is for users to configure themselves in makepkg.conf. Putting this directly in the package may interfere with other user-configurable options and mask errors.

• Removed provides/conflicts because they aren't needed. All packages provides themselves.

• Removed fuzzylite from depends to reduce AUR dependencies and remove a point of failure. The bundled version is statically linked.

• Changed license string because only assets are under CC-BY-SA-4.0, so AND should be removed. Interfere needs to be changed:

  license=(
    'GPL-2.0-or-later' # program
    'CC-BY-SA-4.0'     # assets
  )
  

• Pointed url to the git repo to make checking project status easier.

• Used noextract/bsdtar rather than try to move files around to ensure all and only files from the archive are placed in the target directory.

• Moved sed to prepare() because that is where it's traditionally placed.

• Changes to build() and package() are generally in accordance with cmake package guidelines.

  • Holding options in variable is easier to manage. (No errors from forgotten \.)
  • Removed extraneous mkdir and cd. CMake manages out of tree builds fine.
  • Removed rpath manipulation. Not needed.
  • Removed compiler changes. Users can set CC and CXX in makepkg.conf.
  • Compile and install through cmake, rather than calling the backend directly. This makes it easier for users to change backends.
  • Set build type to None to prevent issues associated with Release. I consider it good practice, even when not strictly necessary, because projects that don't currently alter Release settings could do so in the future. The most common problem I've encountered is setting march=native or equivalent.

[Gigas002]

Thank you very much for your detailed explanations! Learned something new today. I agree with most of your changes, and will try to update my PKGBUILD accordingly in some upcoming time, I think. Maybe piece by piece. I won't change the build type though. I understand the reasoning and problems that could be raised, when march=native used in chaotic-aur, but for users that are building from source I'd prefer to leave it Release.

[xiota]

In this case, build type is inconsequential because vcmi doesn't appear to mess with release settings. If they do in the future, I would encourage switching to None because that would be the best way to ensure settings from makepkg.conf are respected.

As far as phasing in changes, there isn't really any benefit. They've basically already been tested together. Introducing them gradually would require more testing. After the AUR package is updated, the interfere can be dropped in its entirety.

[xiota]

Re-added interfere to use vendored fuzzylite. Given current status of fuzzylite, it shouldn't be used as an independent package until there's a new release.

The last release of fuzzylite was about eight years ago. Although there have been consistent commits over the years, the developer states 7.0 isn't ready, there's no definite timeline, and he has no intention of tagging a new 6.x release. He suggests using the development version from git.

Note: VCMI is the only package in AUR that tries to use the fuzzylite package.