search

godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.11k stars 69 forks source link

Improve GDNative support in the asset library #1198

Open jonbonazza opened 4 years ago

jonbonazza commented 4 years ago

Describe the project you are working on: Any project that uses assetlib

Describe the problem or limitation you are having in your project: From what I understand, in order to publish a GDNative addon to the asset lib, the built binaries need to be hosted in Git so that they can be distributed with the addon, since the assetlib simply pulls from Git. This is not great since having binary files in a Git repo has major downsides.

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

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: I propose that after downloading a project from Git, the assetlib looks for the presence of a Makefile (or Scons, or CMakeList or w/e; something standardized) and if it exists, run it to build the plugin.

If this enhancement will not be used often, can it be worked around with a few lines of script?: Currently, it requires either distributing the prebuilt binaries via Git repo, or leaving the build step up to the user of the addon. Neither of which is ideal, in my opinion. There isn't really any other way around this.

Is there a reason why this should be core and not an add-on in the asset library?: This is about the asset library, so no.

jonbonazza commented 4 years ago

It would also be nice if when a project is opened and there are GDNative addons, but they havent been built yet, the dev is presented with the option to build the addons automatically.

Calinou commented 4 years ago

This sounds like a duplicate of https://github.com/godotengine/godot-proposals/issues/119 to me.

From what I understand, in order to publish a GDNative addon to the asset lib, the built binaries need to be hosted in Git so that they can be distributed with the addon, since the assetlib simply pulls from Git. This is not great since having binary files in a Git repo has major downsides.

You could use a custom download link from GitHub Releases that includes the repository's files with the compiled libraries. However, custom download links can currently only be added by moderators. We could probably soften this requirement to make this easier to do.

I propose that after downloading a project from Git, the assetlib looks for the presence of a Makefile (or Scons, or CMakeList or w/e; something standardized) and if it exists, run it to build the plugin.

This will only work if the user has a C++ development toolchain installed, which is rarely the case for casual users in my experience.

vnen commented 4 years ago

I propose that after downloading a project from Git, the assetlib looks for the presence of a Makefile (or Scons, or CMakeList or w/e; something standardized) and if it exists, run it to build the plugin.

This will only work if the user has a C++ development toolchain installed, which is rarely the case for casual users in my experience.

Also, in many cases the user want the convenience of not having to compile to every target platform. So I prefer that we find a good way to distribute binaries. Users who want to compile probably already know how to do it (assuming you are offering the source in the plugin distribution).

jonbonazza commented 4 years ago

I propose that after downloading a project from Git, the assetlib looks for the presence of a Makefile (or Scons, or CMakeList or w/e; something standardized) and if it exists, run it to build the plugin.

This will only work if the user has a C++ development toolchain installed, which is rarely the case for casual users in my experience.

Also, in many cases the user want the convenience of not having to compile to every target platform. So I prefer that we find a good way to distribute binaries. Users who want to compile probably already know how to do it (assuming you are offering the source in the plugin distribution).

Im open to this as well, but I figured this would be more work, so I opted for a simpler solution.

Calinou commented 4 years ago

Im open to this as well, but I figured this would be more work, so I opted for a simpler solution.

I think it'd actually be less work to document how to use GitHub Releases in tandem with the asset library (for asset authors). We'd need to provide CI setup templates for use with godot-cpp as well.

jonbonazza commented 4 years ago

Oh I misunderstood. I thought @vnen was suggesting something more elaborate.

Does the asset lib already support using files from GH releases?

Calinou commented 4 years ago

Does the asset lib already support using files from GH releases?

Yes, see my reply above:

You could use a custom download link from GitHub Releases that includes the repository's files with the compiled libraries. However, custom download links can currently only be added by moderators. We could probably soften this requirement to make this easier to do.

DrMoriarty commented 3 years ago

Hi All! Recently I implemented my own plugin management system for my own modules. It mostly designed for process binary precompiled modules for third-party SDKs for iOS and Android. There are 37 production ready packages: analytics, ads, social network integration and so on.

The system has dependencies, autoloading gd wrappers, export hooks, uniform module settings for app keys and so on. It can be used as GUI addon and as CLI utility (for example when you want build your project with CI and don't want to store all binary frameworks in github repo. They can be automatically downloaded before your project was build.)

Full info and package list: https://drmoriarty.github.io/nativelib/ GUI Addon: https://godotengine.org/asset-library/asset/824 CLI utility: https://github.com/DrMoriarty/nativelib-cli

What do you think of it?