[build] Remove unused bin/configuration.mk#11580
Merged
Merged
Conversation
`bin/configuration.mk` existed only to persist `CONFIGURATION=<value>` between Unix `make` invocations. CI passes `CONFIGURATION=...` explicitly on every `make` call, and `build.sh` never sets it (so a fresh checkout always hit the `CONFIGURATION ?= Debug` default anyway). Dropping the include lets us delete the only meaningful contents of `Step_GenerateFiles.Unix.cs`, continuing the slow removal of xaprepare. - Drop `-include bin/configuration.mk` from the top of `Makefile`. The `CONFIGURATION ?= Debug` fallback is unchanged. - Delete `build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.Unix.cs` entirely. The `partial void AddUnixPostBuildSteps (...)` declaration in `Step_GenerateFiles.cs` is left as a no-op (legal C#); the call site becomes a zero-cost no-op. `Step_GenerateFiles.Windows.cs` implements a different partial (`AddOSSpecificSteps`) and is unaffected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Removes the Unix make configuration persistence mechanism (bin/configuration.mk) as part of the ongoing cleanup/removal of xaprepare, relying solely on the existing CONFIGURATION ?= Debug default and explicit CONFIGURATION=... passed to make.
Changes:
- Removed
-include bin/configuration.mkfrom the repoMakefile. - Deleted the Unix-only
xapreparegenerated-file step that producedbin/configuration.mk.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| Makefile | Stops including bin/configuration.mk, leaving CONFIGURATION ?= Debug as the sole default mechanism. |
| build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.Unix.cs | Removes the generator that created bin/configuration.mk and the Unix partial-step registration. |
After deleting `Step_GenerateFiles.Unix.cs`, the `partial void AddUnixPostBuildSteps (...)` declaration and its call site in `Step_GenerateFiles.cs` were no-ops. Remove them so the file no longer references a vestige of the `bin/configuration.mk` generator. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
jonathanpeppers
added
the
ready-to-review
simonrozsival
approved these changes
Jun 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
bin/configuration.mkexists only to persistCONFIGURATION=<value>between Unixmakeinvocations. Removing it lets us delete the only meaningful contents ofStep_GenerateFiles.Unix.cs, continuing the slow removal ofxaprepare(see precedent: #11568, #11529).What
-include bin/configuration.mkfrom the top ofMakefile. TheCONFIGURATION ?= Debugfallback at the top of the file is unchanged.build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.Unix.csentirely (it containedGeneratedConfigurationFileand a one-lineAddUnixPostBuildStepspartial that registered it).The
partial void AddUnixPostBuildSteps (Context context, List<GeneratedFile> steps);declaration inStep_GenerateFiles.csis intentionally left in place — partial methods without an implementation are legal in C#, and the call site becomes a zero-cost no-op.Step_GenerateFiles.Windows.csimplements a different partial (AddOSSpecificSteps) and is unaffected.Why this is safe
build-linux-steps.yaml,build-macos-steps.yaml,commercial-build.yaml,azure-pipelines-apidocs.yaml)CONFIGURATION=$(XA.Build.Configuration)on everymakecallbuild.sh(make prepare && make jenkins && make pack-dotnet)make prepareruns against an emptybin/, so the-includeno-ops and?= Debugtakes effect?= Debugstill takes effectmake all?= Debug(nobin/configuration.mkyet)make prepare CONFIGURATION=Releasethen baremake allbin/configuration.mkCONFIGURATION=Releaseon every invocationThat last case is the only behavior change. It was never documented as a contract anywhere in
Documentation/orREADME.md, and developers building Release locally should be passing the flag explicitly anyway.Verification
git grep "configuration\.mk"andgit grep "GeneratedConfigurationFile": zero matches after this change.dotnet build build-tools/xaprepare/xaprepare/xaprepare.csproj: 0 warnings, 0 errors.Path.Combine(..., "configuration.mk")references, no Makefile target depends onbin/configuration.mkas a prerequisite, and the leftover partial-method declaration is benign.