feat: include "nuklear_config.h" when NK_INCLUDE_CONFIG is defined#955
feat: include "nuklear_config.h" when NK_INCLUDE_CONFIG is defined#955sleeptightAnsiC wants to merge 1 commit into
Conversation
sleeptightAnsiC
force-pushed
the
feat_user_config
branch
2 times, most recently
from
3acb495 to
e146fe5
Compare
sleeptightAnsiC
changed the title
sleeptightAnsiC
force-pushed
the
feat_user_config
branch
from
e146fe5 to
9adb7b1
Compare
sleeptightAnsiC
force-pushed
the
feat_user_config
branch
from
9adb7b1 to
9ba68d1
Compare
Adds a way to inject config header with predefined macros and includes. This is not so important for regular users of amalgamated ./nuklear.h but becomes useful when building from ./src/*.c with actual build system See linked issue for more details and reasoning about this. Resolves: Immediate-Mode-UI#886
sleeptightAnsiC
force-pushed
the
feat_user_config
branch
from
9ba68d1 to
ab3b09c
Compare
sleeptightAnsiC
changed the title
| cat <<'EOF' >"${tmpdir}/nuklear_config.h" | ||
| /* intentionally without header guards */ | ||
| static int foo; | ||
| static int bar(void) { return 0; } |
There was a problem hiding this comment.
What are foo and bar? And why are they used in the ci?
There was a problem hiding this comment.
It's a proof that putting arbitrary functions/variables into the config would work fine.
Also ensures that config is being included only once, even without proper include guards.
| } | ||
|
|
||
| static char* | ||
| nk_sdl_dtoa(char *str, double d) |
There was a problem hiding this comment.
Wouldn't it make sense to have this be part of the render instead of the config?
There was a problem hiding this comment.
No, not really.
Every our demo works in the way that nuklear.h has to be included BEFORE the backend.
If I would put it into the backend, it would not propagate correctly to nuklear.h, or would create some kind of circular dependency. It's just not possible without creating a mess. We already talked about something similar at #884 (comment)
There was a problem hiding this comment.
Small note: this thing should be inline, but I had to keep it static for compatibility with C89. It's not a problem when using amalgamation, but it will trigger -Wunused-function when building into separate TUs.
| #ifndef NK_NUKLEAR_CONFIG_H_ | ||
| #include "nuklear_config.h" | ||
| #define NK_NUKLEAR_CONFIG_H_ | ||
| #endif |
There was a problem hiding this comment.
May have missed some previous discussion but this ends up appearing twice? I don't think there are people who include src/nuklear-internals.h... is that the use case?
There was a problem hiding this comment.
I don't think there are people who include src/nuklear-internals.h... is that the use case?
No, it's just to ensure that config propagates correctly there. nuklear_internal.h doesn't include nuklear.h directly. It just "happens" that source files are including those in correct order.
I'll be fine with removing this one, however, maybe we should simply fix the whole nuklear_internal.h inclusion problem in some other PR? I'm already tracking #889 that I could deal with at the same time.
2 participants
Resolves: #886
See linked issue and commit message for more details and reasoning.
I found this to be a rather good moment to submit this feature as I was updating some of my private repos with it. Also I'm planning to share some code that reuses
demo/sdl3_rendererwith differentmain.cfor the purpose of #726 (comment) and #888 (comment), and having its config split into another file will be helpful there.