Manual Build process for Emscripten and Mobile

[frink]

I'd like to be able to build without fips for Emscripten and the Mobile platforms. But fips is so tightly integrated that I'm finding it hard to do a basic Makefiles. Could you add this to the documentation please?

[floooh]

I added some "build-system-agnostic" instructions to the readme a little while ago here (but I just noticed that I missed emscripten there):

https://github.com/floooh/sokol-samples#how-to-build-without-a-build-system

The only two reasons why this is a bit more tricky with the sokol-app samples are:

• some sokol headers must be compiled as Objective-C (on macOS and iOS) or C++ (on UWP), so for the sokol-app samples the sokol header implementations are compiled into a separate library instead of being included right into the sample source code
• the integration of the shader compiler is very build-system specific

For Android the whole process of setting up the Android SDK/NDK and then actually building APKs without a build system is so broken by design that I'd rather skip any instructions (e.g. look at those two python scripts to get an idea what the instructions would need to cover):

• https://github.com/floooh/fips/blob/master/mod/android.py
• https://github.com/floooh/fips/blob/master/tools/android-create-apk.py

I will add a section for building the emscripten samples (under https://github.com/floooh/sokol-samples/tree/master/html5) though, these will all be one-liners once the emscripten SDK has been installed.

[frink]

Cross platform is never as simple as it could be...

It probably makes sense to to put up a YMMV notice on the mobile platforms and just pointing to the build scripts like you did for me is enough. Are there weird scripts for iOS as well?

P.S. - There may be a more elegant way to do things for Android without the whole SDK/NDK. I was just reading this morning in a PR for Dear Imgui (PR:3446) using Gradle... It looked like a lot less gymnastics than using the full SDK/NDK. Seemed promising...

[floooh]

Gradle is just the current "Android build system flavour of the month", this is exactly one of the fundamental problems of the whole Android development workflow: they change build system details all the time, so that nothing works for longer than half a year or so. Using only cmake and calling the underlying tools directly to build the final APK (this is the only part that Gradle actually simplifies) is actually more stable and easier to maintain.

...what the Android SDK would actually need is a compiler/linker wrapper like emcc in the emscripten SDK, which would directly generate ready-to-use APKs the same way that emcc can generate ready-to-use HTMLs, unfortunately this seems to be a too obvious solution for the NDK team to consider ;)

[frink]

I'm new to Android development. Would love to see less build tools used in most projects I work on. I feel Like I spend more time debugging Python and Node than I do writing C sometimes. I wish there was a simple build system that just worked without external dependencies. I've read a few who claim to be. But the tooling is getting ridiculous these days!

[cshenton]

I'll echo this but specific for a sapp application targeting emscripten. Even a pointer to the relevant part of the fips codebase would be a huge helper 👍

[frink]

@cshenton see: https://github.com/floooh/fips/blob/master/cmake-toolchains/emscripten.toolchain.cmake

this seems to be where a lot of the magic config happens...

[frink]

fips is python + cmake

[floooh]

@frink @cshenton the emscripten.toolchain.cmake is a bit overkill, the emscripten-specific samples under

https://github.com/floooh/sokol-samples/tree/master/html5

can actually be built with one-liners, I just need to add a section to the README for this. For instance:

> cd sokol-samples/html5
> emcc clear.c -o clear.html -I [path-to-sokol-headers-dir]
> emrun clear.html

The only reasons that the cross-platform sokol_app.h samples under https://github.com/floooh/sokol-samples are a bit more complicated to build are

1. the shader cross-compilation via sokol-shdc (which is integrated into the build process, but could also run manually)
2. some samples have other dependencies, like Dear ImGui, libmodplug etc...

[frink]

But the html5 samples also include things like ImGui? (e.g. html5/imgui-emsc.cc)

So other than using sokol_app and sokol_imgui providing the scaffolding is there much other diffident between html5/imgui-emsc.cc and sapp/imgui-sapp.cc? The ImGui guts seem nearly identical...

Right now I'm hacking on the samples project adding my own stuff. But I'd really like to remove everything else and have a template project without a hard fips dependencies.

[floooh]

is there much other diffident between html5/imgui-emsc.cc and sapp/imgui-sapp.cc

The platform-specific samples in the d3d11/html5/glfw/metal... directories are essentially tests and examples of using sokol_gfx.h without sokol_app.h. The application-wrapper code (e.g. here https://github.com/floooh/sokol-samples/blob/master/html5/emsc.h, or here https://github.com/floooh/sokol-samples/blob/master/d3d11/d3d11entry.c) is much more minimal and "hacky" than what's in sokol_app.h (or SDL / GLFW), but the actual sokol_gfx.h code is mostly identical to the samples in the sapp directory.

[frink]

Could you for example use:

cd sokol-samples/html5
emcc cimgui-sapp.c [cimgui files] -o cimgui.html -I [path-to-sokol-headers-dir] -I [path-to-cimgui]

In other words, is there any other craziness besides just mapping which files and headers get included?

[floooh]

Yeah basically, in the case of the imgui samples this works because sokol_imgui.h comes with embedded shader code (e.g. sokol-shdc doesn't need to run).

The 3D backend to use isn't autodetected in the source code and must be defined via -D SOKOL_GLES2, but other then that it's just a list of source files and header search paths.

Let's use the imgui-sapp samples, because that requires fewer sources than cimgui-sapp:

> cd sokol-samples/sapp
> emcc imgui-sapp.cc ../libs/sokol/sokol.c ../../fips-imgui/imgui/imgui.cpp ../../fips-imgui/imgui/imgui_demo.cpp ../../fips-imgui/imgui/imgui_draw.cpp ../../fips-imgui/imgui/imgui_widgets.cpp -I../../sokol -I../../sokol/util -I../../fips-imgui/imgui -D SOKOL_GLES2 -o imgui-sapp.html -O3

Or split over several lines for better readability:

emcc imgui-sapp.cc 
../libs/sokol/sokol.c
../../fips-imgui/imgui/imgui.cpp
../../fips-imgui/imgui/imgui_demo.cpp
../../fips-imgui/imgui/imgui_draw.cpp
../../fips-imgui/imgui/imgui_widgets.cpp
-I../../sokol
-I../../sokol/util
-I../../fips-imgui/imgui
-D SOKOL_GLES2
-o imgui-sapp.html
-O3

PS: compiling like this gives you emscripten's default "shell.html" file, it works but looks ugly. To get the WebGL canvas stretched over the entire browser window, add this command line option too:

--shell-file ../webpage/shell.html

[frink]

Thanks for the explanation...

imgui-sapp [...] requires fewer sources than cimgui-sapp...

Assuming cimgui is more difficult because you need both cimgui and imgui sources to compile...?

sokol_imgui.h` comes with embedded shader code [so] sokol-shdc doesn't need to run.

I guess I should next ask about sokol-shdc. Maybe we can pick on an easy example like quad-sapp.glsl...

cd sapp/
sokol-shdc --input quad-sapp.glsl --output quad-sapp.glsl.h --slang=glsl300es

Is that on the right track?

[floooh]

Assuming cimgui is more difficult because you need both cimgui and imgui sources to compile...?

Yes, cimgui is just a C wrapper around ImGui, so you need to add both the cimgui sources and the imgui sources to the compilation.

sokol-shdc --input quad-sapp.glsl --output quad-sapp.glsl.h --slang=glsl300es

Yes. The exact arguments used for the sokol-samples are a bit different, but the above should also work. For reference:

https://github.com/floooh/sokol-tools-bin/blob/d4c5bff725fdac385a04df31846a202917511644/fips-files/generators/SokolShader.py#L39-L46

...also see the documentation:

https://github.com/floooh/sokol-tools/blob/master/docs/sokol-shdc.md

[frink]

Wow digging deeper into this it has problems because installing Emscripten itself is Royal Pain. I ended up adding it as a submodule. Really close to having a Makefile building an app.

The wasm and html generated by my scripts are roughly the same size as the stuff gneerated by fips but my JS file is 121K whereas yours is only 32K from the same sapp file. (I've been modifying the sapp/cimgui_sapp.c file up until now...) Are there some other settings that you're calling to shrink the size of the JS?