greenfork / nimraylib_now

The Ultimate Raylib gaming library wrapper for Nim
MIT License
151 stars 17 forks source link

Broken imports when using physac in module #12

Open fschrofner opened 3 years ago

fschrofner commented 3 years ago

Sorry if it is an issue on my side, I'm still quite new to Nim and raylib.

When importing raylib as well as physac in my main class, everything is working fine and as expected. When I tried to move physac into an own module, though, it seems that imports are broken.

In file included from /home/flosch/.cache/nim/main_d/@mmodule@smodule.nim.c:12:
/home/flosch/.nimble/pkgs/nimraylib_now-0.9.1/nimraylib_now/physac.h:147:5: error: unknown type name ‘Vector2’
  147 |     Vector2 positions[PHYSAC_MAX_VERTICES];     // Polygon vertex positions vectors
      |     ^~~~~~~
/home/flosch/.nimble/pkgs/nimraylib_now-0.9.1/nimraylib_now/physac.h:148:5: error: unknown type name ‘Vector2’
  148 |     Vector2 normals[PHYSAC_MAX_VERTICES];       // Polygon vertex normals vectors
      |     ^~~~~~~
/home/flosch/.nimble/pkgs/nimraylib_now-0.9.1/nimraylib_now/physac.h:162:5: error: unknown type name ‘Vector2’
  162 |     Vector2 position;                           // Physics body shape pivot
      |     ^~~~~~~
compilation terminated due to -fmax-errors=3.
Error: execution of an external compiler program 'gcc -c  -w -fmax-errors=3 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -DPHYSAC_IMPLEMENTATION -DPHYSAC_NO_THREADS   -I/usr/lib/nim -I/home/flosch/Projects/nimraylib_now_issue -o /home/flosch/.cache/nim/main_d/@mmodule@smodule.nim.c.o /home/flosch/.cache/nim/main_d/@mmodule@smodule.nim.c' failed with exit code: 1

My setup looks like:

main.nim
module/module.nim

where main.nim imports:

import nimraylib_now/raylib
import module/module

and module.nim imports:

import nimraylib_now/raylib
import nimraylib_now/physac

When I then try to use physac like so in the module, i run into the issue above:

proc test*()=
    initPhysics()
    let body = createPhysicsBodyRectangle((0.0, 0.0), 32.0, 32.0, 10.0)

I created a git repository containing a minimal example, you can find it here

greenfork commented 3 years ago

That is a lot of input from your side, thank you! I will take a look at it

greenfork commented 3 years ago

Could you please try this:

import nimraylib_now/raylib
import nimraylib_now/physac

proc test*()=
    discard RayWhite
    initPhysics()
    let body = createPhysicsBodyRectangle((0.0, 0.0), 32.0, 32.0, 10.0)

Here we add discard RayWhite so that nim compiler doesn't exclude "unneeded" nimraylib_now/raylib module because RayWhite is defined inside it.

I'm not sure what the correct fix should be to this situation. It doesn't work if I add it directly to physac.nim file. Nim thinks that we don't need this module because it is not used, but we still need it even if it is not used because this nim file also drags the .h file which has required type definitions.

I see that the only reason you add here raylib is to use its conversions tuples to vectors. I had ideas about moving converters to a separate file because they are generally considered broken and if what I said is true for, it will also have a utilitarian purpose.

fschrofner commented 3 years ago

You're right, this fixes the issue.

I see that the only reason you add here raylib is to use its conversions tuples to vectors.

In that minimal example, yes, but in my real project I also use some other methods from raylib.

I had ideas about moving converters to a separate file

This might be a good idea either way, but will it really help with this issue? As physac needs raylib for the Vector2 class, it will also fail in this example:

import nimraylib_now/physac

proc test*()=
    initPhysics()

So it's not just about tuple conversion. I'm kinda surprised, that Nim gets rid of the import although Vector2 is directly used in physac.nim.

greenfork commented 3 years ago

This looks like the issue is with the order of imports:

// /home/grfork/.cache/nim/main_d/@mmodule@smodule.nim.c

/* Generated by Nim Compiler v1.4.4 */
/*   (c) 2020 Andreas Rumpf */
/* The generated code is subject to the original license. */
/* Compiled for: Linux, amd64, gcc */
/* Command for C compiler:
   gcc -c  -w -fmax-errors=3 -DPHYSAC_IMPLEMENTATION -DPHYSAC_NO_THREADS   -I/home/grfork/.choosenim/toolchains/nim-1.4.4/lib -I/tmp/nimraylib_now_issue -o /home/grfork/.cache/nim/main_d/@mmodule@smodule.nim.c.o /home/grfork/.cache/nim/main_d/@mmodule@smodule.nim.c */
#define NIM_INTBITS 64

/* section: NIM_merge_HEADERS */

#include "nimbase.h"
#include "/home/grfork/reps/nimraylib_now/src/nimraylib_now/physac.h"
#include "/home/grfork/reps/nimraylib_now/src/nimraylib_now/raylib.h"
...

Raylib must be imported before physac. Let's see how's the resolution of https://github.com/greenfork/nimraylib_now/issues/5 goes, it might solve this problem too. If not, we will try to somehow affect the order of importing.

jeffmikels commented 2 years ago

This problem exists on Mac too.

greenfork commented 2 years ago

One of the solutions to this problem is to create a single header file out of all other headers. This way we control the order of imports.