add a way to reuse Nuklear configuration across multiple source files

Issues/Immediate-Mode-UI/Nuklear/#886

add a way to reuse Nuklear configuration across multiple source files

Open

sleeptightAnsiCopened 8mo ago

Problems:

Nuklear is configured with macro defines. If you're including it inside of multiple source files, you need to ensure that config stays the same across all of them.
If you change any macro define, you should recompile whole Nuklear and all files using it. If you're using an incremental build system, you may have a problem to detect those changes and all files affected by it.
Nuklear may depend on some specific header coming from other library (e.g. <SDL3/SDL.h> in case you want to reuse SDL's types) and ensuring that this header is available everywhere is complicated
Currently, if you want those problems solved, you need all kinds of hacks to make it behave correctly, either in build recipe or somewhere in Nuklear.
I've created a kicka$$ config for demo/sdl3_renderer, which lets you build this demo on multiple platforms, but due to mentioned limitations, it must live in the main file here, which makes it quite awkward to copy and reuse in your own code (example)
demos with similar backends could reuse the same configuration code, which is currently impossible

I thought about all of these for quite some time, and the solution that I use in my personal branch looks like this. Somewhere at the very top of src/Nuklear.h :

/*
 * Useful when you have a lot of stuff that you want to overwrite
 * Create "nk_config.h" file somewhere and make sure that preprocessor can find it
 * For example, use following compiler flags: -I/path/to/config/dir -DNK_CONFIG
 */
#ifdef NK_CONFIG
  #include "nk_config.h"
#endif

^ This works very well for my build system (custom GNU Make recipe), and I'm pretty sure it should work with everything else too. I've seen this trick used throughout many C libraries. Every private file in Nuklear is including this thing so it solves the problem. We should probably ensure that src/nuklear_internal.h also includes it, and maybe add our own include guards just to make sure, but those are just details that I'll figure out.

If you clicked at the link to the branch from above, you would also notice that I already tried a different solution:

#ifdef NK_CONFIG_FILE
  #include NK_CONFIG_FILE
#endif

^ but this one is impossible to support portably. MSVC does not support this trick to this very day, and trying to support it would require additional macro. I also noticed that passing paths into macro defines at command line (e.g. -Dmacro=/my/path) is very error prone (expansion works differently between compilers and shell types) and so I abandoned this idea entirely.

Any thoughts ?

Activity

30

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

RobLoach8mo ago

I'd be fine with this. Could also ease some of the demo code too.

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems.

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

I'm still having some concerns about this. I'm afraid that people compiling the demos for the very first time might be a bit confused. Also the fact that it looks for exactly "nk_config.h" could cause some problems. EDIT: see https://github.com/Immediate-Mode-UI/Nuklear/issues/886#issuecomment-4390043677

I've seen few PRs related to CMake and some other build systems. Maybe I should tag few people involved in those, as they could be affected by this feature in some way or another.

Hmn....

sleeptightAnsiC8mo ago

Potentially related to:

Tagging anyone who might be affected by this change in some way: @learn-more @trexxet @Xeverous @ModulePillow @chaoticbob @SamuelMarks @riri

(sorry for of a bit of spam, feel free to ignore this one, I just looked through all those PRs and Issues, and thought you might be interested)

What do you guys think? Usually, it's up to the build system to handle configuration, so I think this feature would be beneficial for Cmake recipes (and any other build system really). Do you think this approach will be enough? maybe there is something wrong about it?