Add an easier way to support GDExtensions for both addons and modules, specifically for includes

[Ughuuu]

Describe the project you are working on

A box2d physics server GDExtension.

Describe the problem or limitation you are having in your project

Having to support compilation for both add-on and module(Right now I don't support module builds because of big change, mainly in include headers).

Right now if you are building a module, you have some includes, and if you are building addons, you have other includes.

Eg.

Addon:

#include <godot_cpp/core/class_db.hpp>

Module:

#include "core/core_bind.h"

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Add to godot-cpp an extra set of includes, like indirection includes, that would either use the addon path or the module path. Eg.

#include <godot_cpp/core/extra_class_db.hpp>

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

These extra set of includes would do inside:

#IFDEF MODULE
   #include "core/core_bind.h"
#ELSE
   #include <godot_cpp/core/class_db.hpp>
#ENDIF

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can be used by adding these ifdefs to every addon/module project.

Is there a reason why this should be core and not an add-on in the asset library?

It could also be in another project, eg. godot-cpp-extra, and have those includes there that include then either godot-cpp or godot. But I would rather they are somewhere where they are maintained as first class citizen, eg godot-cpp.

[jordo]

Ya we would really be interested in this as well. Gdextension is quite slow, marshalling in and our of the godot main exe, as well as there is no in lining compiler optimization benefits nor LTO optimization benefit that can stretch across the gdextension/main-exe boundary. Plus we have so many options for our builds... ASAN, SIMD on wasm, omitting frame pointers for our gamerserver profiling, etc, etc.

An absolutely ideal workflow would be to develop game logic in gdextension (with hotreload), but build our final exe's with a statically linked module (which will end up running much faster and also easier to port to a variety of other platforms... (cough cough) ) :D.

[dsnopek]

Thanks for the proposal!

So, if these extra header files (like the example, #include <godot_cpp/core/extra_class_db.hpp>) are part of godot-cpp, does that mean that you'll need to use godot-cpp even when building as a module? If so, this doesn't seem ideal.

As an alternative, I think it could make sense to have godot-cpp generate header files that mirror the internal Godot files (you'd need to maintain a mapping somewhere, maybe in binding_generator.py or an external JSON file that binding_generator.py loads), making a file hierarchy like:

• godot-cpp/
  • gen/
    • include/
      • godot_compat/
        • core/
          • object/
            • class_db.h
        • scene/
          • main/
            • node.h

Then you'd just need to make sure godot-cpp/gen/include/godot_compat gets added to your include path when building as a GDExtension (ie -Igodot-cpp/gen/include/godot_compat). And, this would mean that you wouldn't need to have godot-cpp around when building as a module.

The actual generated *.h files could simply include the *.hpp files. For example, class_db.h could include godot_cpp/classes/class_db.hpp.

As I've mentioned before, I'm not crazy about having to constantly update this mapping, and the fact that every time it changes, it'll break source compatibility for GDExtensions using it. But I think allowing this to be optional, alleviates that. Folks who don't want to build as both a GDExtension and module can continue to use the dependable include paths that won't change.

[Ughuuu]

Ok, tried to implement it here: godotengine/godot-cpp#1415
Still wip but the idea is to use python and regex to look if there is a class inside files, and match based on the classes.

[Ughuuu]

I found another way to do this, for anyone interested: https://github.com/Ughuuu/gdextension-to-module

For the time being I will use this approach.