todo: use same CFLAGS for all demos (general pass for each ./demo/*/Makefile)

[sleeptightAnsiC]

We have some differences in how each demo is being build. This creates few problems mentioned below. I want to make a pass on all of them and make all compilation flags consistent. Here are the changes that I'm considering:

1. Ensure optimizations are disabled with -O0. Currently, few demos use -O2 and waste our CI time. (reference: demo/sdl3_renderer: rewrite Makefile in order to support Emscripten #894 (comment) )
2. Ensure that debug symbols are enabled with -g. This will allow for better debugging without affecting compilation times as much. (I'm still not entirely sure, if it's worth it, but I think it is, GCC enables this by default anyway)
3. Ensure the same C standard with -std=c99 (?) I think some people may disagree so I will quickly explain: Nuklear itself is C89 but the demos are not. Most of the demos already need C99 in some form or another, and even if you aren't getting any pedantic warnings with your setup, you will get them after using #define INCLUDE_ALL. We can keep the backend headers C89 compliant, but we should compile the demos with C99. This was allowed many years ago with 177f391 and if someone disagree, then we should consider rewriting the demos with C89 in mind and reverting said rule, instead of lying about the support with -std=c89. Right now, people are wasting their time for submitting "warning fixes" that someone is about to reintroduce anyway. (EDIT: after grepping the demos, it seems like most are using -std=c89 so maybe my take wasn't so accurate after all, I still think we should talk about it though)
4. Ensure we have the same warnings enabled with -Wall -Wextra -pedantic. Any ideas for other flags? We haven't tested with anything else, but maybe we should...
5. Add missing CIs as few demos do not have them (and this is must have when changing so much stuff)
6. I could also fix this one at the same time: Demo has dependencies and contains paths specific to individual developers' machines #813
7. More... ?

Any thoughts?

cc @RobLoach @rswinkle

[sleeptightAnsiC]

Given that this would be a pretty big change, I will probably separate it into multiple PRs, starting with points 1 and 2 as first PR (because these are the most obvious ones).

grepping shows me there are only three five demos with optimizations enabled, so it shouldn't be such a big deal...

/tmp/Nuklear/demo (master) $ grep -rn '\-O' .
./sdl_vulkan/Makefile:5:CFLAGS += -std=c89 -Wall -Wextra -pedantic -fsanitize=address -O2
./sdl_renderer/Makefile:5:CFLAGS += -std=c89 -Wall -Wextra -pedantic -O2 -DSDL_DISABLE_IMMINTRIN_H
./sdl_opengles2/Makefile:21:    emcc $(SRC) -Os -s USE_SDL=2 -o bin/index.html
./sdl3_renderer/Makefile:21:CFLAGS += -O2
./rawfb/wayland/Makefile:5:CFLAGS+=-std=c99 -Wall -Wextra -pedantic -Wno-unused-function -O3 -fvisibility=hidden

...however, sdl_vulkan seems to be using ASan by default (-fsanitize=address). I would probably also disable this one for the same reason.

[rswinkle]

Any thoughts?

I agree with all of these except possibly 3 since, as you've already noticed, most do use C89. I would be fine switching to C99 for the demos except that then the backends would never be tested with C89 and it would be easy for C99 to slip in there over time. Honestly I don't really care if backends are C99 since they aren't Nuklear proper, and anyone who really wants C89 could make the few changes necessary in a few minutes.

I definitely appreciate 6. I think I skipped those backends in my past PRs changing backends.

[riri]

To me Nuklear core should kept with c89, and to make demos compiling in c99 it's necessary to make 2 compilation units (breaking some demos themselves if I remember well).
I could build the whole in c89 with all demos included adding the flag -D_XOPEN_SOURCE=500 on linux to have the snprintf() symbol from stdio.h. I don't know if any flag is necessary on other platforms but I don't like such specific flag on a platform agnostic demo :)

Maybe focusing on demos structure (like it was begun with the common directory) would clarify what needs to be done to have:

• quick recompilation if the core on one side and common demos on another side are compiled separately
• better Makefile to easily enable including various demo parts

[sleeptightAnsiC]

Yea, I do agree my initial take on -std=c99 is a bad idea.

Btw, we now have a separate CI task that only compiles core library (./.github/ci_compile_sources.sh) but this is too little to enforce C89, so I totally agree that demos should do -std=c89 (it's just too late to change at this point)

I just want those demos to compile with unified -std= and warnings, and right now some of them use C99 while others C89, and it's quite confusing to deal with. Do you guys happen to know why these specific demos use all of those shenanigans?

/tmp/Nuklear/demo (master) $ grep -rn '\-std=c99' .
./rawfb/wayland/Makefile:5:CFLAGS+=-std=c99 -Wall -Wextra -pedantic -Wno-unused-function -O3 -fvisibility=hidden
./glfw_opengl2/Makefile:5:CFLAGS += -std=c99 -Wall -Wextra -pedantic
/tmp/Nuklear/demo (master) $ grep -rn '\-D_' .
./xcb_cairo/Makefile:24:        $(CC) $(SRC) $(CFLAGS) -D_POSIX_C_SOURCE=200809L -o bin/$(BIN) ${LDFLAGS}
./x11/Makefile:5:CFLAGS += -g -std=c89 -Wall -Wextra -pedantic -Wno-unused-function -D_POSIX_C_SOURCE=200809L
./rawfb/x11/Makefile:13:        $(CC) $(SRC) $(CFLAGS) -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L -o bin/$(BIN) -lX11 -lXext -lm

^ is it because of some headers not being C89 compliant?

[sleeptightAnsiC]

Also, since you're already here, maybe we should consider removing this from reviewer's guide...

Nuklear/Readme.md

Line 155 in a329721

Reviewing changes to `demo/*`, `example/*` and other files in the repo:

Nuklear/Readme.md

Lines 160 to 161 in a329721

	* Use of newer C features, or even other languages is not discouraged.
	* If another language is used, ensure that the build process is easy to figure out.

...because right now, I've seen few contributors (myself included) being confused about people trying to fix C89 demo compatibility with bunch of obscure hacks (instead of relying on well supported non-C89 features).

I feel like this paragraph was neither properly enforced nor actually needed by anyone. It's just misleading.

[riri]

I just want those demos to compile with unified -std= and right now some of them use C99 while others C89, and it's quite confusing to deal with. Do you guys happen to know why these specific demos use all of those shenanigans?

 /tmp/Nuklear/demo (master) $ grep -rn '\-std=c99' .
 ./rawfb/wayland/Makefile:5:CFLAGS+=-std=c99 -Wall -Wextra -pedantic -Wno-unused-function -O3 -fvisibility=hidden
 ./glfw_opengl2/Makefile:5:CFLAGS += -std=c99 -Wall -Wextra -pedantic
 /tmp/Nuklear/demo (master) $ grep -rn '\-D_' .
 ./xcb_cairo/Makefile:24:        $(CC) $(SRC) $(CFLAGS) -D_POSIX_C_SOURCE=200809L -o bin/$(BIN) ${LDFLAGS}
 ./x11/Makefile:5:CFLAGS += -g -std=c89 -Wall -Wextra -pedantic -Wno-unused-function -D_POSIX_C_SOURCE=200809L
 ./rawfb/x11/Makefile:13:        $(CC) $(SRC) $(CFLAGS) -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L -o bin/$(BIN) -lX11 -lXext -lm

^ is it because of some headers not being C89 compliant?

x11 is the right way, as always (just kidding ^^). More seriously, I never think of writing a safe ansi c code without -std=c89 -Wall -Wextra -Werror -Wpedantic, and on a posix platform _POSIX_C_SOURCE=200809L makes sense and could be the default for core, and can be enough for some demos (sdl3_renderer compiles well with just that, even with INCLUDE_ALL defined)

One issue is that demos using stb_image (demos with file browser, skinning and extended examples) wont compile with pedantic on c89 (because using features from more recent standard) so it's getting complicated to rely on c89 without major changes in demos, examples, and maybe some backends.

Due to how demos are made and organized, it's not possible to align to c89.

[sleeptightAnsiC]

Not really related to this task anymore, but I thought I would mention it anyway:

demos using stb_image [...] wont compile with pedantic on c89 (because using features from more recent standard)

IIRC those were mostly caused by C++ comments // and upstream didn't want to fix it (nothings/stb#1328). I remember writing some POSIX AWK script for replacing // and preserving their logical structure (but I don't remember where I put it, so I'll probably have to start over...)