Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

raylib.h: Add relevant defines to types #2198

Closed

Conversation

greenfork
Copy link
Contributor

Allow order-independent includes so that other library files can
be included before raylib.h.

This fixes greenfork/nimraylib_now#12 and greenfork/nimraylib_now#49 of my Nim bindings. The problem is that Nim doesn't know how to include C files in order. And this seems as a generally good approach to use.

Allow order-independent includes so that other library files can
be included before raylib.h.
@raysan5
Copy link
Owner

raysan5 commented Dec 7, 2021

Actually those defines were created to allow other files to check for them while keeping the raylib-required types. The problem with this change is that if other files define custom types before raylib, then many raylib internals could broke due to not getting the expected type.

@raysan5 raysan5 closed this Dec 7, 2021
@greenfork
Copy link
Contributor Author

The problem with this change is that if other files define custom types before raylib, then many raylib internals could broke due to not getting the expected type.

Could you please clarify this part? In order for other files to break raylib code, they need to define RL_VECTOR2_TYPE and similar defines. If they do so, they probably know what they do. Current change will only affect code such as

#include "physac.h"
#include "raylib.h"

where includes don't have to be in the specific order. In other cases we assume that no other file is going to define RL_VECTOR2_TYPE which is a good enough assumption since this define is quite unique.

@raysan5
Copy link
Owner

raysan5 commented Dec 10, 2021

@greenfork I prefer to force the use of raylib defined types and do not allow other previously included files to redefine them (even they know what are they doing), it could suppose a security concern if that is allowed.

Other files using same types could be included after that and use the defines to check for them if required.

@greenfork
Copy link
Contributor Author

@raysan5 alright, thanks for explaining.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Broken imports when using physac in module
2 participants