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

C#: Let platforms signal if they support the mono module or not #88245

Merged
merged 1 commit into from
Feb 18, 2024

Conversation

shana
Copy link
Contributor

@shana shana commented Feb 12, 2024

Instead of hardcoding platform names that support C#, let platforms set a flag indicating if they support it or not. All public platforms except web already support it, and it's a pain to maintain a patch for this list just to add additional names of proprietary console platforms, or when adding new platforms in general.

It will make it much easier to add new platforms or variants of existing platforms if we prefer having the platform signal what it supports instead of having hardcoded "if env.platform == X" checks. Platform flag checking scales much better in the long run and lets us keep both platforms and modules more clean and portable.

/cc @akien-mga @raulsntos @mhilbrunner

Contrbuted by W4Games ❤️

@raulsntos
Copy link
Member

Since the platform support is usually implemented in the .NET module, I feel like it makes more sense for the .NET module to say if it supports it or not. But I agree that for your use case it may make sense to be able to signal support from your end since you're the one implemented that support, I don't know how that looks like though so I'm not sure I can come up with alternative suggestions.

That said we already have .NET-specific code in the platform export plugins to detect unsupported configuration (e.g.: Android 32-bit architectures) so, since we're already "leaking", I'm not strongly against it.

However, if we add this, I do think it'd be preferable to be a "supported" flag rather than "unsupported" so that other platforms that know nothing about .NET don't accidentally signal support, if that makes sense.

@shana
Copy link
Contributor Author

shana commented Feb 13, 2024

Since the platform support is usually implemented in the .NET module, I feel like it makes more sense for the .NET module to say if it supports it or not. But I agree that for your use case it may make sense to be able to signal support from your end since you're the one implemented that support, I don't know how that looks like though so I'm not sure I can come up with alternative suggestions.

Yeah, it's a tough one. When all the platforms and modules are in one single monolithic codebase, it's easy to have that responsibility on the module side. But when we're adding platforms out of source, it suddenly just doesn't scale to have a ton of local patches saying "oh and this platform too" scattered everywhere outside platform folders. I'm trying to move these "if platform == X" checks that we have everywhere, where the module/driver/etc is the one making the decision, to a model where the platform signals what it supports (via flags or defines or similar generic checks). It will be much easier to add new platforms, or variants of existing platforms, when we're no longer hardcoding platform names.

However, if we add this, I do think it'd be preferable to be a "supported" flag rather than "unsupported" so that other platforms that know nothing about .NET don't accidentally signal support, if that makes sense.

Yeah, I was going back and forth on that, whether to add a supported flag to all of them minus web, or this. I can do the supported flag, it makes sense.

Instead of hardcoding platform names that support C#, let platforms
set a flag indicating if they support it. All public platforms
except web already support it, and it's a pain to maintain a patch
for this list just to add additional names of proprietary console
platforms.

This makes adding new platforms or variants or existing platforms
much easier, as the platform can signal what it supports/doesn't
support directly, and we can avoid harcoding platform names.
@shana shana force-pushed the simplify-mono-support-detection branch from 30272a0 to 21e524a Compare February 13, 2024 21:52
@shana shana requested review from a team as code owners February 13, 2024 21:52
@shana
Copy link
Contributor Author

shana commented Feb 13, 2024

I've updated this to use a supported flag instead. I can't decide whether to have this generic flag as an array (that we can extend in the future for other checks of this type in other places overall), or have a specific mono_supported boolean flag just for this check. Let me know what you think!

Note: this will, of course, not solve the whole problem of letting platforms control their mono support, because we still hardcode dynamic library extensions in gd_mono.cpp and harcoded platform_ENABLED ifdefs, but I do have some other upcoming patches to make those bits more flexible for new platforms 🙂

@shana shana changed the title C#: Let platforms signal if they *don't* support it C#: Let platforms signal if they support the mono module or not Feb 13, 2024
@Riteo
Copy link
Contributor

Riteo commented Feb 17, 2024

@shana

I can't decide whether to have this generic flag as an array

That's the first thing that popped to mind when I've seen this PR. My take would be, in true Godot style, to not try to predict the future and just stick with the simple mono_supported flag. If we'll ever need more things we can always add a new system down the line.

After all we're not working with "user-space" APIs here ;)

Edit: I just reviewed the thing and I can see that it didn't take much to make the thing "generic" (I thought that it would've been more complex). It's perfectly fine like this :D

Copy link
Contributor

@Riteo Riteo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I love these kind of improvements :D

@akien-mga akien-mga modified the milestones: 4.x, 4.3 Feb 17, 2024
Copy link
Member

@akien-mga akien-mga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@akien-mga akien-mga merged commit 033821c into godotengine:master Feb 18, 2024
16 checks passed
@akien-mga
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants