Split into .c and .h files

[eloraiby]

when the .h file is referenced from multiple .c files, compilation performance suffers (on low-end devices: ARM, lowend x86/x64, ...) as well as IDE performance. Splitting it to .c and .h files would reduce that enormously.

PROS:

• Compilation Time
• Linting/intellisense performance
• Ability to package sokol into a shared library
• Reduce readability overhead
• Having a shared library, makes it easy to make wrappers for other languages

If you still have to do that, you can include one intermediate header file that include both .c and .h files

Note: Nuklear started by having a header only file, then ended up doing the split

[floooh]

Yeah, controversial topic I know, but I'll keep sokol header-only.

Some reasons:

• configuration-defines don't spill out into the build system, instead you can put them right before the implementation includes
• when compiling on MacOS, a .c file wouldn't work because the implementation contains Objective-C code, so there would have to be a sokol_gfx.c with just the C code, and another sokol_gfx.m file with just the Obj-C parts
• I consider the STB headers the reference, and those have been working just fine for many projects
• compilation time difference isn't measurable, and will most likely be less when packing all header-only libs of a project into a single implementation source file (similar to a unity build), the implementation code is skipped, not parsed (since there are no inline functions like in many C++ header-only libs), integrating sokol_gfx.h into Oryol has actually reduced compile time by a about 7 seconds

To integrate the sokol headers into a bigger project, you would basically provide the sokol.c / sokol.m file yourself:

https://github.com/floooh/sokol-samples/blob/master/sapp/sokol.c

https://github.com/floooh/sokol-samples/blob/master/sapp/sokol.m

Apologies for closing this issue, but this is one of those topics where both sides have valid arguments and it comes down to endlessly discussing personal preference ;)

[eloraiby]

No worries :)
these can be baked into one header file, using the same approach as nuklear using a script.

Would you merge a pull request that does that ?

[floooh]

Would you merge a pull request that does that ?

Not at the moment, I need to think more about it. Right now it's not a high priority, but this might change as more headers are added.

I'm aware of the merge-script approach that nuklear uses since quite recently, but I would need to figure out how to automate the merge during the edit/compile/test loop (could be done with a fips/cmake custom build step I guess).

FYI, sokol_gfx.h also started in separate pieces, not C-files, but one header file per 3D-backend which was then included by the top-level sokol_gfx.h.