Ability to control logging system, SSDP, and other "release vs debug vs headless" options more granularly via appmanifest

[swajj]

Is your feature request related to a problem? Please describe (REQUIRED): I'd like to know exactly what engine features are enabled in my build and fine-tune them so I have more control over build sizes and attack surfaces.

For example, right now, I can use "release" build to disable logging, SSDP, and other features, or "debug" to keep them. A "headless" build appears to leave all the debug features enabled. (while disabling other features e.g. graphics output) Does headless build have SSDP? What if I want headless without SSDP, or perhaps logging?

Describe the solution you'd like (REQUIRED): Ideally, the three default build types would be documented and defined in terms of "appmanifest" flags, and I could then simply fine-tune them via a custom appmanifest file to create any variation of "debug" vs "release" vs "headless" features, and be confident in exactly what is in my build.

The appmanifest itself is also not well-documented; users are redirected to an external tool to create one and the example in the documentation doesn't actually contain any flags. Ideally, all possible "flags" that could appear in an appmanifest would be documented.

Describe alternatives you've considered (REQUIRED): I'm unaware of any other way to solve this short of a hand-rolled engine build.

[swajj]

A related use case I'm explicitly interested in is "release build, but with logging". Would be great for internal testing.

[AGulev]

A related use case I'm explicitly interested in is "release build, but with logging". Would be great for internal testing.

If your issue concerns having logs in the release build, it's already possible to address this using a simple native extension. Please take a look at this native API: dmLogRegisterListener.

Here are a few examples of how to use it:

1. Poki SDK example on GitHub
2. Defold Share Log on GitHub (Note: the dmLog namespace is deprecated, see documentation for the newer API).

If this addresses the main practical case for now, I'm closing this ticket. Feel free to open a new one if you need something else.

[swajj]

The logging was one example - doing it via a native extension works fine, even if it would be easier to just flip a switch for Defold's own implementation.

The ticket was originally written because I was told I could probably do a "headless release" build via appmanifest, but the documentation for appmanifests doesn't cover any of the things that I know are different between debug/release.

e.g. I don't feel like I have ANY of these:

• Insight into exactly what the differences are between debug, release, and headless
• Granular control over those items individually
• Documentation on all the possible appmanifest flags

The first I've pieced together over time from docs and conversations, but the other two are still open questions to me, and go further than simply rewriting a log extension.

[britzl]

• Insight into exactly what the differences are between debug, release, and headless

I added some additional information about the differences here: https://github.com/defold/doc/pull/430

Granular control over those items individually

This can to some extent be done through the app manifest. In the case of "release mode with logs" you currently need to use the solution provided by Alexey. This solution is used by others and is well tested.

Documentation on all the possible appmanifest flags

Here: https://github.com/defold/doc/pull/431 Also: https://defold.com/manuals/extensions-build-variants/#combined-context