Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
Ughuuu opened this issue Mar 1, 2024 · 3 comments · May be fixed by godotengine/godot-cpp#1415
Open

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

Ughuuu opened this issue Mar 1, 2024 · 3 comments · May be fixed by godotengine/godot-cpp#1415
Labels
topic:gdextension

Comments

@Ughuuu
Copy link

Ughuuu commented Mar 1, 2024

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.
@Ughuuu Ughuuu changed the title Add a way to support GDExtensions for both addons and modules Add an easier way to support GDExtensions for both addons and modules, specifically for includes Mar 1, 2024
@jordo
Copy link

jordo commented Mar 5, 2024

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
Copy link

dsnopek commented Mar 12, 2024

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
Copy link
Author

Ughuuu commented Mar 15, 2024

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 Ughuuu linked a pull request Apr 6, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic:gdextension
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Generate compatibility layer Ughuuu/godot-cpp
4 participants
@dsnopek @jordo @Ughuuu @AThousandShips