Well @Aciid and @NeoNacho who commented upthread (disagreeing with one another) are probably the main two people you’d have to convince.
@NeoNacho said he would rather limit the build settings to really important ones. So with that in mind it would be worth elaborating what your specific use cases are.
So far only platform conditionals have been mentioned. If they are really the main impetus, maybe they could be targeted directly by adding to the current list of settings understood and managed automatically by SwiftPM. Right now we have
Xcode). Platform conditionals are so important they are baked right into the Swift compiler, so maybe always supplying direct equivalents to C targets would be reasonable:
As Swift evolves, the list would be kept in sync with the
os(...) directive, with new additions and aliases as needed.
That would get you reliable platform conditionals for even less work than configuring a C setting, and it would not require evolving the manifest API. How well would that handle your use case? Even if it turns out to not be helpful at all, it illustrates the sort of questions that need to be sorted through at this point: Why do we want prefix headers? Are prefix headers really the best way to accomplish that goal (since we have a fresh slate and can design absolutely anything)? So for whatever your other use cases are, try to think about them the same way and report back what you come up with.
P.S. If we go this route we may as well just complete the entire list at once: