CHANGE: Allow (internal) input module to define input event packing alignment

[ekcoh]

Description

Spike illustrating (with a minimal example) how to move responsibility/code from package down to module when it cannot be dictated by package anyway or is not a package responsibility. In this case this is illustrated with a Unity version check to conditionally define a symbol, in this case UNITY_INPUT_SYSTEM_INPUT_MODULE_DEFINES_EVENT_PACKING_ALIGNMENT which reflects the availability of a "feature" (constant in this case - could be any code) in internal module that may be relied upon instead of hard-coding assumptions or logic into package code that depends on definitions by module. The intention is to move code where it logically belongs and to simplify changing behaviour and reduce chance of mistakes by relying on a single definition.

It seems like Unity assembly defines is the only reliable way to solve this at compile-time to keep it constant.

In this example NativeInputEvent (internal) is added to event buffers in native code and a new constant (requires specific Unity branch - see related internal ticket) defines the packing alignment selected by native code. By relying on this constant defined by module, the package could automatically adopt to changes to alignment without updating the package.

Testing status & QA

No tests added, existing tests pass. This is not surprising since the PR doesn't change any behavior.

The PR should be quality assured with. the specific Unity branch and an older Unity version to prove the point.

Overall Product Risks

Minimal

• Complexity: Small - Compilation time
• Halo Effect: Small - Package only

Comments to reviewers

Review for alignment on approach.

Changelog has intentionally been left out since there is no functional change apart from internal / implementation details.

See comment on asmdef if you are testing this branch with the associated Unity branch.

Checklist

Before review:

• Changelog entry added.
  • Explains the change in Changed, Fixed, Added sections.
  • For API change contains an example snippet and/or migration example.
  • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
  • Jira port for the next release set as "Resolved".
• Tests added/changed, if applicable.
  • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.

After merge:

• Create forward/backward port if needed. If you are blocked from creating a forward port now please add a task to ISX-1444.

[ekcoh]

Note that this is only to allow this PR to be tested with the Unity branch (internal). It would have to be updated to the Unity version containing the actual update to module before this PR could land.

[ekcoh]

If you are testing this branch consider updating this to whatever Unity version number the associated Unity branch has.

[jfreire-unity]

This is great and I'm happy to see this in. I'm not aware of any risk on doing this but 6.3 sounds like a good start.

Could you elaborate more on why the compilation time increased with this? Is it noticeable?

[Pauliusd01]

LGTM, checked main testing/sample scenes in playmode and player on 6000.2.0a11, 6000.1.2f1 and 2022.3.61f1

[ekcoh]

This is great and I'm happy to see this in. I'm not aware of any risk on doing this but 6.3 sounds like a good start.

Could you elaborate more on why the compilation time increased with this? Is it noticeable?

Increased compilation time? I cannot recall seeing that or did someone else comment or mention it?