Closed ZauberNerd closed 2 months ago
~~I'm not too well versed in the .pbxproj
file format, but is the assumption correct, that the XCConfigurationList
of the "first target" is always the same as the XCConfigurationList
of the PBXProject
that the rootObject
points to?
And would it make sense then (in a follow-up PR) to use the rootObject
instead of the first target throughout the entire project?~~ Nevermind - after inspecting the file a bit more I figured out, that there are build configuration lists for native targets and for the project itself.
After thinking about this a bit more - I think this change doesn't make much sense. It would need the ability to select which target it should read instead of always using the first target.
So the API of getBuildProperty
would need to have another parameter for the target
:
// option 1 - would be a breaking API change
project.getBuildProperty(property: string, target: uuid, build: string) => string|void;
// option 2 - feels a bit unnatural in my opinion, because target is a parent of build
project.getBuildProperty(property: string, build: string, target: uuid) => string|void;
// option 3 - would be in line with other method signatures, but feels clumsy to have an options object
// for just one property
project.getBuildProperty(property: string, build: string, opts: { target: uuid }) => string|void;
@alunny @imhotep what are your thoughts on this?
Before this change the
getBuildProperty
method would iterate over all targets and their build configurations without an early exit when the property was found - that sometimes lead to having the value of a build property from a later project.After this change the
getBuildProperty
method will search through all buildConfigurations (or a single one, if specified) of the first project target and return as soon as the requested property has been found.This PR can also be used as basis for follow-up PRs, for example: The
productName
getter can use this internally to get thePRODUCT_NAME
of the correct target. (which in turn would fix: #91 / #99)This PR would probably make this workaround in react-native obsolete.