-
Notifications
You must be signed in to change notification settings - Fork 124
Create a new product type so the PIF remains platform agnostic #826
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a new product type so the PIF remains platform agnostic #826
Conversation
{ | ||
_Domain = darwin; | ||
Type = ProductType; | ||
Identifier = org.swift.product-type.common.object.bundle; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to a better identifier if anyone would like to suggest one....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bundle would be good to avoid since it has a specific existing meeting. Maybe just org.swift.product-type.common.object.target?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if anything is relying on the prefix being com.apple.product-type, but I guess this is a good test to find out if that's the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe I just drop bundle? target
seems a bit odd since its a product type identifier.
so some what about one of these:
org.swift.product-type.common.object
or maybe ?org.swift.product-type.common.object.type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
forget that last one... type is already there...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok... going with org.swift.product-type.common.object
@swift-ci test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once we figure out naming
PackageTypes = ( | ||
com.apple.package-type.mach-o-executable | ||
); | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the objects have no differing properties across Windows/Darwin/Unix, should we just put one single spec in the global domain for simplicity rather than 3 separate ones?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Over the years we deduplicated the same kind of thing across macOS and iOS to avoid similar redundancies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The windows one inherits from a different product type, so that one is somewhat unique
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I missed that. That's a little unfortunate; I'd hoped to avoid platform-specific product type hierarchies as much as possible but we could always change this sort of thing later.
PackageTypes = ( | ||
com.apple.package-type.mach-o-executable | ||
); | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I missed that. That's a little unfortunate; I'd hoped to avoid platform-specific product type hierarchies as much as possible but we could always change this sort of thing later.
5081c07
to
10b8c19
Compare
@swift-ci test |
Closes #610