Allow creating export presets that inherit from other presets

[KoBeWi]

Describe the project you are working on:
Mobile Android game.

Describe the problem or limitation you are having in your project:
To save APK size, it's recommended to export for various architectures separately and upload multiple APKs. Cool, but this means multiple export presets and unfortunately, things like project version or permissions are stored in the preset too, so each time I want to increment version or change permissions I have to remember to set it for each preset.

Another thing is, I have a preset that that is used for debug only and it has all architectures enabled. My problem here is that Export All button literally exports all, including presets I don't want to export right now. Which means that if I want to skip one, I have to export everything else manually.

Describe how this feature / enhancement will help you overcome this problem or limitation:
My proposal is this: when you create a preset, aside from duplicate, you'd have an option to "Inherit Preset". This creates a duplicate preset, which will inherit all values from it's parent preset and if you change parent preset, changes are reflected in the inheriting preset. Also you can override some values in the preset, so they aren't inherited anymore. Think of scene instances.

Exporting a preset with child presets, would export only the inheriting presets (so the inherited one becomes "abstract"). It's basically "Export All", but for groups, not everything.

Bonus for ability to mark preset as "Release Only".

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:
Nothing interesting here.

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

Is there a reason why this should be core and not an add-on in the asset library?:
Not doable with any reasonable script. Unless we consider hacky plugins viable.

[Calinou]

Implementing support for Android App Bundles would make this less of a necessity, as Google Play will do the hard work of splitting architectures for you.

[KoBeWi]

Bump, I just came up with a new, very practical use case - demos. I want to create demo export. A demo export consists of "demo" feature tag and list of excluded assets. I can configure it all fine for a preset, but I want to export for multiple desktop targets. This means I have to keep multiple presets in sync.

This kind of modifies the original proposal, because it would be really useful if the inherited presets could be target-independent, i.e. consist of common stuff like the mentioned tags or assets and you could inherit it for different targets. It would make them much easier to maintain. I once shipped wrong build, because my presets were not synchronized, so this way I could avoid such errors. For this reason probably a "General" dummy target would have to added for the sake of inheriting presets.

[AlecAcosta]

This would be very useful since I do 3 exports (an apk, an aab, an apk without iap) and for every one I have to manually check and uncheck the export options needed and change the name and the folder each one goes to.
I could duplicate the base export preset but then I have to update manually every change in version and other potential changes so having the inherited presets would save time

[KoBeWi]

Coming back here, I had a similar problem in my newest project, but came with a novel solution xd

I deleted export_presets.cfg file completely and instead created export profile "templates". I have a custom build system based on a Python script that exports the project from command line and creates the profiles on the fly using the templates. This way I don't have to worry that they are out of sync.

This is a sophisticated workaround, but I think it's more flexible than the default profile workflow will ever be. I think I could make the script generic enough to be usable in other projects 🤔

[jasonwinterpixel]

Would there be value to having the export presets be a resource & not use 'export_presets.cfg'?

Should each export target be a resource? Would we gain consistency and value from that? There be an export_presets.res that holds sub resources in a tree such that each node of the tree inherits the parent node's properties and adds overrides? Would that be too confusing to new users?

[jasonwinterpixel]

Maybe we can write a generic resource type that allows overriding values from a parent resource. Then we can use that to allow sharing of export values between export targets. I'm worried the user interface for setting that up will be awkward to communicate to the user, however.

I think the list of resources to export is a an issue that requires more advanced features in addition to being shared between export targets.

I want to be able to match filename patterns, ie: add files that match res://audio/*.ogg. Add res://scenes/SomeScene.tscn and its dependencies. Add folders and all the contents. (currently adding a 'folder' just adds the items that are currently in the folder, adding new items to the folder wont add them to the resource list)

[DanielKinsman]

It would be very handy to be able to specify non-resource files to include or exclude in the export once rather than having to do it in every single export template. I shot myself in the foot by missing a text file in one of my export presets, there are so many for XR and I don't own them all to test on.

[KoBeWi]

I made this addon: https://github.com/KoBeWi/Godot-Project-Builds

[Calinou]

It would be very handy to be able to specify non-resource files to include or exclude in the export once rather than having to do it in every single export template. I shot myself in the foot by missing a text file in one of my export presets, there are so many for XR and I don't own them all to test on.

There could be a project setting that acts as a base list for non-resource export filter. Individual export presets could then add on top of this base list. This could also address #10227.