[3.0] Exanite's Tracking Issue

[Exanite]

Exanite's Tracking Issue

This tracks a bunch of miscellaneous tasks that I accumulated while working on Silk 3.
I'm open for anyone to work on these tasks, but please discuss with me in the Silk Discord first.

In-progress

Tasks in progress will be moved to the corresponding pull request.

Uncategorized

This section contains informal reports, suggestions, or complaints about Silk 3.
I'm logging them here so they don't get forgotten about until I either open a formal issue or address them.

From Aqua:

• libSDL3.so is humongous (should not be nearly 14 MB)
  • Exanite: I checked my system version and that one is only 3 MB. I'll have to verify what the expected size is since I'm not familiar with binary stripping.
• Silk 3 does not prefer its own native binaries?
• Go through the thread Aqua has made: https://discord.com/channels/521092042781229087/1512914692853465088

From Ethereal:

• SilkTouch generator takes an immense amount of RAM: https://discord.com/channels/521092042781229087/607634593201520651/1513592461493145601
  • I need to also check with Curin to see how much RAM their device has. If their device doesn't have enough RAM, this might explain why the Microsoft job takes so long (aside from it already processing a lot of data).
  • Run the Microsoft job locally and see how much RAM it takes on my device.

High priority

Bindings:

• Begin work on the rest of the Khronos bindings
  • I'd like to start this early because this lets us spot issues early and we can use these as test cases for the rest of the changes.

Bindings usage:

• OpenAL context should be disposable
  • This is noted in the OpenAL.Tutorial001.HelloSound project
  • Check other API contexts as well for the same issue

Documentation:

• Add Vulkan smoke test project
• Differentiate between smoke tests and actual tutorials/examples. I would categorize the current SDL/OpenAL "tutorials" in Silk 3 to be smoke tests since they really shouldn't be referenced as sources of best practices.
• Generator usage: Explain SilkTouch CLI options
• Generator usage: Clarify that SilkTouch does not modify non .gen.cs .cs files during the Generated Bindings Output section

Maintenance:

• Consider reworking data type trimming regexes.
  • This was discussed more here: [3.0] Implement name-related improvements identified in previous Vulkan PR #2503 (comment)
  • The summary is that the current set of 2 regexes doesn't elegantly handle the case where the ending of a word should not be trimmed, but the word itself can have data type suffixes.
  • For example: alSourceRewindv and alSourceRewind. The d in Rewind can be mistaken as a data type suffix, so we add it to the EndingsNotToTrim regex. However, the dv in Rewindv also has the same problem.
  • We likely need something more akin to WordsNotToTrimInto than EndingsNotToTrim.
• Consider implementing a IsProbablyABitmask function based on BuildTool's IsProbablyABitmask for identifying flags enums
  • Original comment: [3.0] Implement name-related improvements identified in previous Vulkan PR #2503 (comment)
• Consider removing ModCSharpSyntaxRewriter
• Add SilkConstants class to generator
  • Ideally all magic numbers and constants are consolidated here and documented.

Multithreading / isolation:

• Fix issues when running multiple jobs
  • Figure out why the headers are getting mixed up when running multiple jobs at the same time.
    • Seems to be related to TransformFunctions.
  • Figure out why the SDL handle structs are getting named as Silk.NET.SDL.ConditionHandle.gen.cs instead of ConditionHandle.gen.cs when running multiple jobs at the same time.
• Maybe rework how using statements are added. Not sure why, but using statements are randomly added/removed between Windows/Linux. This causes noisy diffs.
• Investigate how DI is set up in this project. I believe it is the core cause of the multi-job isolation issues. I need to verify this, but the jobs seem to share the same mod instances instead of being separated. This would explain why we need to access data by job key instead of it being simply injected into the mod instances.

Medium priority

Quality:

• Add some way of verifying our bindings are well polished.
  • These would mainly involve simple automated sanity checks that ensure our bindings our consistent. Could be done as a separate CLI project from SilkTouch.
  • Check for missing namespaces.
    • This was an issue discovered during [3.0] Split up ExtractNestedTyping and add tests for TransformHandles #2587. I've fixed one case of these, but haven't verified the rest of the generated files (since there's way too many to manually verify).
  • Check for spelling/casing issues? Identifiers like Sdl.PropGpuDeviceCreateDebugmodeBoolean are technically correct (native name is SDL_PROP_GPU_DEVICE_CREATE_DEBUGMODE_BOOLEAN, so Debugmode is "one" word), but we could have an audit tool that checks for these non-ideal cases so we can add manual overrides. Worth the effort? Probably not unless we care about perfecting the bindings.

Low priority

CI:

• Figure out how to handle CLA properly. Currently native builds will block CLA due to the use of a bot account.
• Prevent native builds from triggering unnecessarily when the PR description is edited
  • Native builds should only trigger once. If the last commit in the PR is from the native builds workflow, it should not run again.
• Figure out how to make our CI workflows work with forks.
  • I did some testing here and got a proof-of-concept working: https://github.com/Exanite-Dev/GithubActionTesting
  • Note that we need to be careful about security here. This involves escalation of privileges.

Maintenance:

• Consider opening a ClangSharp PR to fix issue with SDL_MAX_SINT64 generation on Linux
  • More context: https://discord.com/channels/521092042781229087/1376331581198827520/1443401810822828113
  • public const nint SDL_MAX_SINT64 = unchecked(0x7FFFFFFFFFFFFFFF); does not compile

High level utilities:

• Reimplement the Vulkan struct chaining API
• Add image format utils for Vulkan/etc

IDE / Metadata:

• Ensure SupportedApiProfiles attributes are correct
  • Properly resolve API profiles for Flags/FlagBits types
  • Prefer name from NativeName for resolving API profiles
• Consider optimizing NativeName attributes.
  • This should involve renaming StripAttributes to CleanupAttributes and adding an option in its config to optimize NativeName attributes.
  • Also see: [3.0] Implement name-related improvements identified in previous Vulkan PR #2503 (comment)

Completed

Completed during #2588:

• Switch to SLNX solution format to improve readability/mergability
• From Ethereal: They had a CSharpier TypeLoadException when running the Win32 job on develop/3.0. Might be related to the error I saw half a year ago. If so, likely can be fixed by simply updating CSharpier. CSharpier has updated their Roslyn package since then.

Completed during #2591:

• Port back the --only option from Curin's branch so I don't need to specify --skip for all but one job

Not doing

For transparency and for reference, I'll move any tasks I don't plan on doing here.
I recently added this section (Jun 5th, 2026) so this section is currently empty.