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.

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

Change "minimal" dependency feature to package feature #17

Closed
wants to merge 1 commit into from

Conversation

nikitalita
Copy link

When "minimal" was added as a feature, examples and itest included the godot package with the feature "minimal".

As a result, when building the workspace, even if the workspace is compiled with --no-default-features, it will still only run godot-codegen with the "minimal" feature set. If we change it so that the dependency feature is enabled by a package feature which is on by default, we can then compile the workspace with --no-default-features and get the codegen for the full class set.

@Bromeon
Copy link
Member

Bromeon commented Nov 7, 2022

A bit of background:

The minimal feature was a bit of a hack to allow shorter dev cycles, as codegen took a huge amount of time for all the classes. I'm not sure if we want to support it long-term, the distinction is also rather arbitrary.

But we can gladly improve the way this is handled until then. Technically, features should be additive (specifying an extra feature should add functionality, not remove it), so I'm doing it wrong. If we went that way, we would have to:

  • instead of minimal, have a counterpart codegen-full, which generates everything when active, and the minimal set when inactive
  • have codegen-full on by default (so people can just use the library without getting errors)
  • let itest and maybe demo use this (untested):
    [dependencies]
    godot = { path = "../../godot", features = ["convenience"], default-features = false }

I didn't do it like this so far, because it's less convenient than just specifying minimal. In particular, packages need to list all the features if no-default-features is set, meaning that we have to maintain this "default" list in several places.

However, someone just running cargo build in the workspace would still have the minimal set enabled, even if only one package uses it... So maybe we should change it. Your example on the other hand would require cargo build --no-default-features in the workspace, whereas most people naturally don't add that command line argument.

What was your circumstance to build the workspace but require full codegen? The library itself doesn't need it. Did you want to generate documentation?


Apart from that, maybe only the itest should have a minimal set at all (for faster CI), and the examples should specify dependencies closer to how the user would do it.

@Bromeon Bromeon added bug c: tooling CI, automation, tools labels Nov 7, 2022
@nikitalita
Copy link
Author

I was just dicking around seeing how certain classes that weren't in the minimal set got generated. I wanted to see how you were handling properties on classes that had their default setters and getters as protected methods (it turns out the answer was "not").

@Bromeon
Copy link
Member

Bromeon commented Nov 8, 2022

Yeah, codegen is not yet feature-complete. Properties, constants, etc. still need to be exposed 🙂

What do you think about having a codegen-full feature instead of minimal? Would that address your issue?

@nikitalita
Copy link
Author

Yeah that would work for me.

@bors bors bot closed this in 6d0507e Dec 16, 2022
Hapenia-Lans pushed a commit to Hapenia-Lans/gdextension that referenced this pull request May 26, 2023
# This is the 1st commit message:

Parse gdextension_interface.h declarations using regex

# This is the commit message #2:

AsUninit trait to convert FFI pointers to their uninitialized versions

# This is the commit message godot-rust#3:

GodotFfi::from_sys_init() now uses uninitialized pointer types

# This is the commit message godot-rust#4:

Introduce GDExtensionUninitialized*Ptr, without changing semantics

# This is the commit message godot-rust#5:

Adjust init code to new get_proc_address mechanism

# This is the commit message godot-rust#6:

Make `trace` feature available in godot-ffi, fix interface access before initialization

# This is the commit message godot-rust#7:

Compatibility layer between Godot 4.0 and 4.1 (different GDExtension APIs)

# This is the commit message godot-rust#8:

Add GdextBuild to access build/runtime metadata

# This is the commit message godot-rust#9:

Detect 4.0 <-> 4.1 mismatches in both directions + missing `compatibility_minimum = 4.1`

# This is the commit message godot-rust#10:

Detect legacy/modern version of C header (also without `custom-godot` feature)

# This is the commit message godot-rust#11:

CI: add jobs that use patched 4.0.x versions

# This is the commit message godot-rust#12:

Remove several memory leaks by constructing into uninitialized pointers

# This is the commit message godot-rust#13:

CI: memcheck jobs for both 4.0.3 and nightly

# This is the commit message godot-rust#14:

Remove ToVariant, FromVariant, and VariantMetadata impls for pointers

This commit splits SignatureTuple into two separate traits:
PtrcallSignatureTuple and VarcallSignatureTuple. The latter is a child
of the former. PtrcallSignatureTuple is used for ptrcall and only
demands GodotFuncMarshall of its arguments. VarcallSignatureTuple is
used for varcall and additionally demands ToVariant, FromVariant, and
VariantMetadata of its arguments, so pointers cannot benefit from the
optimizations provided by varcall over ptrcall.

# This is the commit message godot-rust#15:

Adds FromVariant and ToVariant proc macros

# This is the commit message godot-rust#16:

godot-core: builtin: reimplement Plane functions/methods

# This is the commit message godot-rust#17:

impl GodotFfi for Option<T> when T is pointer sized and nullable godot-rust#240

Additionally FromVariant and ToVariant are also implemented for Option<Gd<T>>
to satisfy all the requirements for ffi and godot_api.

# This is the commit message godot-rust#18:

Fix UB in virtual method calls that take objects
Fix incorrect incrementing of refcount when calling in to godot
Fix refcount not being incremented when we receive a refcounted object in virtual methods

# This is the commit message godot-rust#19:

fix UB caused by preload weirdness

# This is the commit message godot-rust#20:

Implements swizzle and converts from/to tuples
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug c: tooling CI, automation, tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants