File ghc-wai.changes of Package ghc-wai

Analysis of previous modifications and failures:

- What was changed previously:
  - Setup.lhs was modified to filter out the -fobject-determinism flag from the command-line arguments passed to the Setup executable. Additional helper functions and a temporary ghc wrapper were added to try to ensure any ghc subprocesses also avoid receiving the unsupported flag.

- Observed failure after those modifications:
  - The build log still shows ghc-9.10.2 being invoked with -fobject-determinism during the `./Setup configure` step.
  - This indicates that the flag removal did not take effect for the configure action. Possible reasons:
    - The packaged Setup.lhs modifications were not actually used by the build (e.g. wrong archive repackaging, archive uploaded but spec still uses remote Source0; however the build log indicates Setup was compiled and run, so the modified Setup may have been used).
    - The offending -fobject-determinism comes from an argument nested inside a --global/--ghc-options string that is not parsed/filtered by the simple argument transformation used before defaultMain. The spec passes a `--global '--ghc-options=-fobject-determinism -fhide-source-paths  '` token: complex quoting may have prevented strip-and-filter logic from removing the flag.
    - The Setup/Cabal code may merge or pass flags to ghc later than when we altered getArgs, or may be invoking ghc via an absolute path (/usr/bin/ghc), bypassing PATH wrapper. A wrapper on PATH helps only if child processes pick it up; if Cabal uses the absolute ghc path or stores ghc path earlier, wrapper is ineffective.

Repair plan (minimal, targeted):

1) Modify Setup.lhs to override the configure hook rather than only munging getArgs.
   - Use Distribution.Simple's hooks to replace confHook with a small wrapper that strips "-fobject-determinism" from the ghc-options carried in the ConfigFlags passed to the configure phase.
   - This ensures that even if flags are provided via a single --ghc-options=... string, or via --global, the flag will be removed right before the configure action constructs ghc invocations.
   - Keep the previously added argument-filtering logic as a defense-in-depth measure (minimal extra code retained).
   - Remove the fragile ghc wrapper mechanism (or keep it if harmless), but the core fix is to alter confHook.

2) Implementation details (to be made in Setup.lhs):
   - Import Distribution.Simple.Setup and Distribution.Simple.LocalBuildInfo (as needed).
   - Define a function sanitizeGhcOptions :: String -> String that removes occurrences of "-fobject-determinism" from a space-separated option string, preserving other flags and surrounding whitespace.
   - In the new confHook, take the ConfigFlags argument and:
       * For optghc in ConfigFlags (or the appropriate field representing --ghc-options), apply sanitization.
       * For other fields that may carry ghc options (e.g. program configuration), ensure removal if present.
   - Call the original confHook with the modified flags to continue the normal configure flow.

3) Repack the source archive and upload, then run the build and observe logs.
   - After implementing the confHook modification, compress the package root back to wai-3.2.4.tar.gz and upload via the existing OBS upload step.

Rationale for minimality:
- Changing the confHook targets the exact point in Cabal where ghc options are used for configure; this is a minimal, robust approach compared to broader refactors or changes to the spec.
- It avoids relying on PATH wrappers or brittle string manipulation of the raw program args alone.

Next steps I'll perform:
- Edit extracted/wai-3.2.4/Setup.lhs to add a confHook wrapper implementing the sanitization.
- Repack and upload the archive.
- Trigger the build and check the results; if further failures appear, iterate focusing only on the new failure reason.


(End of repair plan)