webrtc with conan or docker

[blockspacer]

Hi, webrtc requires complex build process. Original webrtc requires boringssl, while most of open-source projects require openssl (can't use boringssl and openssl at same time, so need to patch and build webrtc from source)

I hope my draft (only for pre-built webrtc) will be helpful to integrate conan-webrtc or Dockerfile support
https://github.com/blockspacer/conan-webrtc/

[Faless]

Hi @blockspacer, thanks for your interest in this project.

in Godot Engine, since version 3.1, we use mbedtls and not openssl (it's much more lightweight and easier to embed).

I do provide pre-built libwebrtc for Linux and Windows (I've been looking to provide OSX build for a while, but I don't have a Mac and didn't have the time to find an alternative solution yet). See this repo.

I never heard of conan before (can you provide some context or reference? I couldn't find much googling around).

Among other things, we have been investigating an alternative to libwebrtc that we could include directly in the godot build system (see #12) and rawrtc seems the best candidate so far (though I haven't seen much activity lately).

[blockspacer]

@Faless

conan is awesome C++ Open Source Package Manager https://conan.io/

it can be used with scons, makefiles, pre-built binaries, CMake like so https://jfreeman.dev/blog/2019/05/22/trying-conan-with-modern-cmake:-dependencies/

If Godot used conan + scons, then it would be easier to integrate Godot modules with apps (especially important if you want to create server with custom netcode and main loop, but integrate some Godot modules, like physics).

scons is not popular and it is big downside of Godot. conan can solve a lot of problems.

i created separate issue about Godot + scons + conan godotengine/godot#37180

Note that alternatives to google-libwebrtc may be not stable (protocol changes by browser vendors), buggy, have bad performance (libwebrtc from google supports multi-threading and it is really important). I hope that chosen solution will be production ready and have active community (libwebrtc from google is production ready).

[Faless]

Well, if it's a package manager then I guess people can use it to package godot or this plugin.
I don't really see why it should be supported upstream.
Simply make the package like distros do for godot (debian, fedora, etc).
Am I missing something?

[blockspacer]

@Faless

people can use it to package godot or this plugin.

yes, anyone can wrap into conan packages existing Godot scons scripts, webrtc binaries e.t.c. But it may be not trivial to keep conan packages up-do-date without help of original repo maintainers, especially as solo contributor

BTW conan can solve a lot of problems, for example - plugin management, integration with existing open-source or closed-source software, CI/CD pipeline e.t.c.
see (plugin management Godot issue): godotengine/godot-proposals#607

[Faless]

yes, anyone can wrap into conan packages existing Godot scons scripts, webrtc binaries e.t.c. But it may be not trivial to keep conan packages up-do-date without help of original repo maintainers, especially as solo contributor

Well, but then you are asking us to do the work that the conan community should do.

I don't really see any advantage in using this specific technology honestly.

see (plugin management Godot issue):

That is mostly about GDScript plugins, not sure how this software would help in any way

[blockspacer]

@Faless

I don't really see any advantage in using this specific technology honestly.

to

1. not create your own dependency-management solution and use existing (free, opensource, popular and stable)
2. allow to use Godot modules in other projects (that don't use scons, for example). Currently engine forces game-server developers to run whole Godot engine (just disabling graphics is not enough), even if you don't need to run GDscript on game-server.

Please look at talk about managing deps in complex projects and why scons/make/CMake is not enough https://www.youtube.com/watch?v=S4QSKLXdTtA

That is mostly about GDScript plugins, not sure how this software would help in any way

conan allows to manage deps not only for C++. For example, GDScript plugin may be packed into archive during conan create command. In game-project-dir conanfile stores deps of created package and can unpack created plugin during conan install command with auto-resolving deps (no recursive deps problem).

Again, idea is simple: game project lists required plugins in custom conanfile. during conan install all required plugin files must be unpacked at some destination folder. Engine is able to detect plugin folders (for example by file watcher or re-import button, as done with assets) and auto-install plugins.

[Faless]

2\. allow to use Godot modules in other projects (that don't use scons, for example). Currently engine forces game-server developers to run whole Godot engine (just disabling graphics is not enough), even if you don't need to run GDscript on game-server.

as others explained. this is not possible, since modules depends on the rest of godot code.

[Faless]

Again, idea is simple: game project lists required plugins in custom conanfile. during conan install all required plugin files must be unpacked at some destination folder. Engine is able to detect plugin folders (for example by file watcher or re-import button, as done with assets) and auto-install plugins.

Wouldn't we need to ship conan with godot? Would it work on all platforms (e.g. Android/iOS/HTML5)?

[Faless]

Let's continue the discussion in the proposal repository I guess.

[blockspacer]

@Faless

BTW

this is not possible, since modules depends on the rest of godot code.

It is fine to run not only physics module with custom game server. I think that main problem here is that Godot provides no way to customize main application loop.

Suppose you are switching to Godot from other engine and you already created some server-side netcode (C++). If you could link with Godot as library and run only desired engine systems in main loop (no need to run renderer.Update() on server, but need to run physics.Update() e.t.c.), than that engine-switching process will be a lot easier.

[Faless]

Suppose you are switching to Godot from other engine and you already created some server-side netcode (C++). If you could link with Godot as library and run only desired engine systems in main loop (no need to run renderer.Update() on server, but need to run physics.Update() e.t.c.), than that engine-switching process will be a lot easier.

There is already a server version of godot which does not do the rendering part

[blockspacer]

@Faless

There is already a server version of godot which does not do the rendering part

One way to fix that problem is to modify Godot server version code. But there is no way to create custom server (completely separated from Godot repo) that links with Godot as library and uses custom main loop.