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 %<ID>%). 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]

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?

[codecov-github-com[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

@@           Coverage Diff            @@
##           develop    #2176   +/-   ##
========================================
  Coverage    68.11%   68.11%           
========================================
  Files          367      367           
  Lines        53610    53610           
========================================
  Hits         36519    36519           
  Misses       17091    17091           

Flag	Coverage Δ
mac_2021.3_pkg	5.40% <ø> (ø)
mac_2021.3_project	70.37% <ø> (ø)
mac_2022.3_pkg	5.18% <ø> (ø)
mac_2022.3_project	65.23% <ø> (ø)
mac_6000.0_pkg	5.19% <ø> (ø)
mac_6000.0_project	68.03% <ø> (ø)
mac_6000.1_pkg	5.19% <ø> (ø)
mac_6000.1_project	68.03% <ø> (ø)
mac_6000.2_pkg	5.19% <ø> (ø)
mac_6000.2_project	68.02% <ø> (ø)
mac_trunk_pkg	5.19% <ø> (ø)
win_2021.3_pkg	5.41% <ø> (ø)
win_2021.3_project	70.44% <ø> (ø)
win_2022.3_pkg	5.18% <ø> (ø)
win_2022.3_project	65.31% <ø> (ø)
win_6000.0_pkg	5.19% <ø> (ø)
win_6000.0_project	68.10% <ø> (-0.01%)	:arrow_down:
win_6000.1_pkg	5.19% <ø> (ø)
win_6000.1_project	68.10% <ø> (ø)
win_6000.2_pkg	5.19% <ø> (ø)
win_6000.2_project	68.10% <ø> (-0.01%)	:arrow_down:
win_trunk_pkg	5.19% <ø> (ø)
win_trunk_project	68.10% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...unity.inputsystem/InputSystem/Events/InputEvent.cs	87.50% <ø> (ø)

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.