Need Help Compiling Crispy DOOM

“~> haikuporter chocolate_doom
Checking if any package-infos need to be updated …
Looking for stale dependency-infos …
Warning: skipping chocolate_doom-3.0.0, as it is broken on the target architecture.
Error: No version of chocolate_doom can be built”

After having received this error, I removed the haikuports directory and recloned it via git.

I ran the port on chocoate and it acted as if it was working, but then ended with this list of complaints which tells me something about my system is broken somehow.

    xproto-7.0.23_git is still marked as untested on target architecture
    updating dependency infos of xrick-021212
    updating dependency infos of xtrans-1.3.5
    xut-0.2.1 is still marked as broken on target architecture
    xxhash-0.6.5 is still marked as untested on target architecture
    xxhash-0.6.4 is still marked as untested on target architecture
    xz_utils-5.2.4 is still marked as broken on target architecture
    updating dependency infos of yab-1.7.5.6
    updating dependency infos of yab_ide-2.2.8a
    yacreader-9.0.0 is still marked as broken on target architecture
    yaddns-1.1 is still marked as broken on target architecture
    yamagi_quake2-7.30 is still marked as broken on target architecture
    yaml_cpp-0.6.2 is still marked as broken on target architecture
    yaml_cpp-0.5.3 is still marked as broken on target architecture
    updating dependency infos of yasm-1.3.0
    yate-6.0.0 is still marked as broken on target architecture
    ykclient-2.15 is still marked as untested on target architecture
    youcompleteme-20180809 is still marked as broken on target architecture
    updating dependency infos of youtube_dl-2018.11.07
    z26-2.16.00s is still marked as broken on target architecture
    updating dependency infos of zaz-1.0.0
    zeal-0.6.1 is still marked as broken on target architecture
    zeromq-4.2.5 is still marked as broken on target architecture
    updating dependency infos of zip-3.0
    updating dependency infos of zlib-1.2.11
    updating dependency infos of zookeeper-2.1.1
    updating dependency infos of zope_interface-4.4.3
    zopfli-1.0.2 is still marked as broken on target architecture
    updating dependency infos of zsdx-1.11.0
    updating dependency infos of zsh-5.6.2
    updating dependency infos of zstd-1.3.7
    updating dependency infos of zsxd-1.11.0
    updating dependency infos of zziplib-0.13.69

haikuporter chocolate_doom_x86

It says that chocolate_doom_x86 was not found in the repository.

Why would you leave query support out? It’s especially easier to find files in the haikuports and sources files.

Please check your haikuports.conf configuration file. It should state which secondary architecture are enabled (in your case x86).

Told here by forum members as quicker I/O when using a lot of files (specially removing). That statement is true if you try to work with massive filecount projects (~46k files) like NodeJs, GTK or stuff like Firefox (checked here).

I dont use the Haiku UI as i spend 95% of the time in ssh connections (unless i’m trying some UI kit for example), so the find command works as well as other in other cases/OSs. Would the query support help there?

There is an overhead, but it’s not noticeable on a SSD. I wouldn’t recommend disabling queries, except those special usecases you mentioned.

Surely yes, but… you know… i dont really have a SSD in my laptops :man_shrugging: , plus i work in virtual machine environments… so the overhead is noticeable.

If i had one… then… maybe… who knows.

EDIT: I believe I corrected my error.

Lurking in the forums i read about the “–get-dependencies” param to haikuporter. While it may install stuff that you may not want/notice… works great for quick testing of packages or raw packaging without testing.

Very nice tool for sure.

There we go, yes that saved me a lot of time!
Chocolate has compiled, though when I try a round with GzDOOM, I don’t get the same story, though I appear to have the libs and development libs it claims I lack… at least I thought so…

"waiting for build package gzdoom_x86-3.6.0-1 to be activated
Building …
– Could NOT find BZip2 (missing: BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
– Using system zlib, includes found at /boot/system/develop/headers/x86
– Using system jpeg library, includes found at /boot/system/develop/headers/x86
– Using internal bzip2 library
– Using system gme library, includes found at /boot/system/develop/headers/x86
– Checking for module ‘gtk±3.0’
– No package ‘gtk±3.0’ found
– Checking for module ‘gtk±2.0’
– No package ‘gtk±2.0’ found
CMake Error at /boot/system/data/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find SDL2 (missing: SDL2_INCLUDE_DIR)
Call Stack (most recent call first):
/boot/system/data/cmake/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
cmake/FindSDL2.cmake:181 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
src/CMakeLists.txt:177 (find_package)

– Configuring incomplete, errors occurred!
See also “/sources/gzdoom-g3.6.0_legacy/build/CMakeFiles/CMakeOutput.log”.
See also “/sources/gzdoom-g3.6.0_legacy/build/CMakeFiles/CMakeError.log”.
Warning: Command ‘[‘bash’, ‘-c’, ‘. /wrapper-script’]’ returned non-zero exit status 1
Error: Build has failed - stopping."

Seems like you miss SDL2 devel package(which is on the repos)…

GTK2 or GTK3 are not on the repos, nor probably will soon, so i hope that the software skips them and takes SDL2 instead.

Edit the FindSDL2.cmake file:

...
   HINTS
     ${_sdl2_SEARCH_DIRS}
   PATH_SUFFIXES
-    include/SDL2 include
+    include/SDL2 include SDL2
)
...

So just add SDL2 to the list.
Example is from a different project, feel free to find the correct place for the adjustments.
- and + is the diff output, it means replace the line with the another. Study diff/patch to get more info.

Or pass the -DSDL2_INCLUDE_DIR="/system/`echo ${relativeIncludeDir}`/SDL2" to cmake.

Btw: do we really have to have a porting topic here?

I will attempt duplicate your instruction tomorrow after work, thank you.

And no, the topic has gone above and beyond the subject of compiling Crispy DOOM alone, though I was going to wrap back to that eventually once I had acquired the education to do so.

When that time comes, I will be attempting to learn how to add Crispy-DOOM to the archive with it’s own receipt, as well as figuring out why I can not compile Crispy Heretic, Hexen, or Strife like I can DOOM.

Though like I said, I’m not there yet with my understanding. I know basic compiling technique and am simply eager to learn how to take things to the next step, especially in regards to compiling for Haiku.

Hope I am not a pain in anyone’s butt. :slight_smile:

1 Like

REminiscence bulds for sdl , the newer version builds ok with SDL2 (slow) but it’s missing a library (PR for that is still open: https://github.com/haikuports/haikuports/pull/3157)
https://user-images.githubusercontent.com/16057090/46230962-87608700-c36a-11e8-8596-321485c9e5e2.png