Splitting up the Raylib modules further (audio, textures, text)

[ajusa]

Hello,

Thank you so much for the excellent Nim wrapper of raylib. One feature that I would like to request is for the modules to be split up closer to what Raylib itself offers. For example, splitting out raudio, textures, text, etc. My specific use case involves just playing audio, so I don't want to have to compile in all of the GUI/X11 related dependencies if possible.

[greenfork]

Thank you for your kind words!

Regarding your request, do I understand correctly that you would like to link a separate raudio.c file with RAUDIO_STANDALONE option and use the header file just for this file?

As I can see from raudio.c file, the RAUDIO_STANDALONE does not modify the API and just modifies existing behaviors. So it should be possible to use it. Would that be possible for you to try the following:

1. Get that raudio.c file into the same src directory as your executable
2. At the top of your source file add something like {.compile: "raudio.c".}, as in example here
3. Compile your executable with -d:nimraylib_now_linkingOverride, as can be seen from here, this disables any attempts to link the files

My understanding is that you can use same header as raylib.h even if the implementation of the C file does not completely contain all declared functions. And that should mean that we can use same raylib.nim file here as well.

Let me know if you have any troubles with that.

[ajusa]

Hm, I had to do that alone with pulling in many of the external header files that raudio uses and putting them in the correct directory. After doing that though, I ended up with the following error:

/usr/bin/ld: raudio.c:(.text+0x66b5b): undefined reference to `TRACELOG'
/usr/bin/ld: raudio.c:(.text+0x66b9d): undefined reference to `TRACELOG'
/usr/bin/ld: raudio.c:(.text+0x66be0): undefined reference to `TRACELOG'
/usr/bin/ld: raudio.c:(.text+0x66c74): undefined reference to `TRACELOG'

Not sure if I have the wrong version of raudio, this is from the 3.7 release.

[ajusa]

I changed some of the compile flags, now it looks like this: nim c -r -d:nimraylib_now_linkingOverride --threads:on --passC:-DRAUDIO_STANDALONE

The current error is

/home/ajusa/Documents/ajmp/raudio.c: In function ‘LoadWave’:
/home/ajusa/Documents/ajmp/raudio.c:719:16: error: incompatible types when assigning to type ‘Wave’ from type ‘int’
  719 |         wave = LoadWaveFromMemory(GetFileExtension(fileName), fileData, fileSize);
      |                ^~~~~~~~~~~~~~~~~~
/home/ajusa/Documents/ajmp/raudio.c: At top level:
/home/ajusa/Documents/ajmp/raudio.c:728:6: error: conflicting types for ‘LoadWaveFromMemory’
  728 | Wave LoadWaveFromMemory(const char *fileType, const unsigned char *fileData, int dataSize)
      |      ^~~~~~~~~~~~~~~~~~
/home/ajusa/Documents/ajmp/raudio.c:719:16: note: previous implicit declaration of ‘LoadWaveFromMemory’ was here
  719 |         wave = LoadWaveFromMemory(GetFileExtension(fileName), fileData, fileSize);
      |                ^~~~~~~~~~~~~~~~~~
/home/ajusa/Documents/ajmp/raudio.c:838:6: error: conflicting types for ‘ExportWave’
  838 | bool ExportWave(Wave wave, const char *fileName)
      |      ^~~~~~~~~~
In file included from /home/ajusa/Documents/ajmp/raudio.c:69:
/usr/include/raudio.h:146:6: note: previous declaration of ‘ExportWave’ was here
  146 | void ExportWave(Wave wave, const char *fileName);               // Export wave data to file
      |      ^~~~~~~~~~
compilation terminated due to -fmax-errors=3.

My knowledge of C is pretty rusty, not really sure why this is causing an error.

[greenfork]

Thank you for the attempts! It looks like it needs a lot more effort then. I'm a bit worried that this will grow too large since I already support 2 different versions of mangled/not mangled versions due to conflicting names on Windows machines. I should have free time in a week or two, I will take a look what could be sensible, it might be easy to do too.

About the dependencies, do I understand correctly that these were only the files listed here, or you had to do any additional chores?

And last question, do you plan to use it together with the whole Raylib or just as a single unit with no intention to use any other units from Raylib? I think in the output you provided happens exactly that, some conflicting files are included several times.

[ajusa]

Sorry about that, I should have provided at least a bit more information:

My directory structure looks like this:

├── ajmp.nim
├── config.h
├── external
│   ├── dr_mp3.h
│   ├── dr_wav.h
│   ├── jar_mod.h
│   ├── jar_xm.h
│   ├── miniaudio.h
│   └── stb_vorbis.h
├── music.mp3
└── raudio.c

With ajmp.nim looking like this:

import os, nimraylib_now

{.compile: "raudio.c".}

initAudioDevice()      #  Initialize audio device

let music = loadMusicStream("music.mp3")         #  Load MP3 audio file
music.setMusicPitch(1)
playMusicStream(music)
while true:
   music.updateMusicStream()
   sleep(20)

And the command to compile is the same as above, nim c -r -d:nimraylib_now_linkingOverride --threads:on --passC:-DRAUDIO_STANDALONE ajmp.nim

So basically the only additional libraries I had to add (other than required dependencies) was config.h.

I plan on using this without any other parts of Raylib. I'm making a super small headless music player that suits my needs, so I shouldn't need any other Raylib modules.

[greenfork]

Alright, thank you! Looks like it should be relatively easy to do, I will try to implement it in the nearest future.

[greenfork]

@ajusa to give a heads up here. I didn't get to work on it as it appears a lot more complicated than just adding a few lines of code. The problem is that right now I support 2 separate ways of packaging raylib C library - by statically compiling it and by linking it dynamically. With support for separate modules this matrix splits yet again into more derivations which looks too complicated.

I think the right way is to drop dynamic linking and always compile statically. And then add ability to compile only specific parts of the raylib library instead of the whole package. I would like to hear your thoughts on this and whether you found any solution to this problem yet.

Dynamic linking looks as a less priority than separate packages from raylib. And I don't think I can afford to support it all.

[greenfork]

Note to self: the raylib.h file can actually be fully substituted by its parts as shown in janet bindings https://github.com/janet-lang/jaylib/tree/master/src. The problem is that raylib.h is specifically tweaked to be easy to parse, other files will require special handling and probably contributions to the source. Currently we do specific parsing for raygui, raymath and physac - this is not a very pleasant experience.