Split out Xcode build configuration to separate files about react-native-test-app HOT 13 CLOSED

None of the settings used in those xcconfig files seem to actually influence the compilation of the host app in a functional way, are they really needed in this context?

Regardless, because of how xcconfig files work, there is no easy way to inherit from one xcconfig file into another. You can include them as is actually done in those examples, but it’s a very manual process.

Finding a way to automate that in the react-native-test-app should, I think, require us to have an example that actually enables functional changes in the test app.

from react-native-test-app.

I don’t think we need to do that inclusion, we can just assign those xcconfig files at the project level. I’ve created a PR for this branch that does that #143

from react-native-test-app.

@HeyImChris: Would you be fine with us not migrating over those config files?

from react-native-test-app.

Spoke separately from this thread, but we shouldn't work in projects with custom build settings. There's Microsoft internal owiki guidance here as to why

from react-native-test-app.

That strategy makes sense to me, but what does it mean for this thread?

from react-native-test-app.

Not sure I know what you're getting at. This issue is still unresolved so we should move the build settings for this project out of the pbxproj? Ideally before consumption

from react-native-test-app.

Re-reading the thread, there appear to be 2 subtly related questions—or perhaps, quite possibly, I’m the only one thinking of those:

1. The question @tido64 asked was spurred by an example like https://github.com/microsoft/fluentui-react-native/tree/master/apps/ios/src, which I understood to mean ‘do we need to provide users the ability to bring their own xcconfig’ (in a generic manner)?

2. And then there’s the question wether or not the react-native-test-app Xcode project itself should use a xcconfig file for any of its custom build settings.

As for question 1; I wonder if the specific example at hand should be enough to consider this right now, as it seems like these build settings may not strictly be needed in this context. Although having said that, I guess there’s the possibility (or perhaps even goal?) to completely retire such custom example apps, in which case the react-native-test-app would be the place to surface build warnings like these. Is that the case?

As for question 2; I don’t even know if there really are any react-native-test-app specific build settings? If they exist and don’t happen to clash with those provided typically by CocoaPods, then a simple solution would be to assign the xcconfig to the project level, rather than the target level that CocoaPods uses.

from react-native-test-app.

For question 1: I'm not even sure it makes sense to give users the ability configure react-native-test-app. In most cases, you'd want to configure your own native code. @alloy correct me if I'm wrong but this is possible to define in your .podspec. So I don't see the need to add this ability at this time.

For question 2: I played around with this and could not get CocoaPods to not overwrite the .xcconfig files to use. I extracted some settings and set it in the source .pbxproj, made sure that it got picked up, but when I try to consume it, CocoaPods would replace them with the generated ones. The only options I see here is to either 1) modify the final .pbxproj to use the supplied ones and #include the .xcconfig files generated by Pods or 2) #include the supplied .xcconfig files in the generated ones. In either case, we would have to implement a pod post-install script that would do this, and make sure that it will work with each upgrade of either CocoaPods or Xcode.

In the long run, I'm not sure this is worth the effort. react-native-test-app use default settings for pretty much everything. It is a test app, to be consumed by frameworks/libraries that need one. It is not intended to be checked in. It is hidden from view on disk, and will get wiped away with git clean.

Now, going back to the PR that started this conversation, I don't believe that this issue should be a blocker to merge microsoft/fluentui-react-native#302.

@HeyImChris, what are your thoughts?

from react-native-test-app.

👍

I extracted some settings and set it in the source .pbxproj, made sure that it got picked up, but when I try to consume it, CocoaPods would replace them with the generated ones.

This sounds like a bug in CocoaPods, but if there’s no great need for this feature right now for react-native-test-app then we probably don’t need to burden the CocoaPods team with that at this time either.

from react-native-test-app.

For question 1: I'm not even sure it makes sense to give users the ability configure react-native-test-app. In most cases, you'd want to configure your own native code. @alloy correct me if I'm wrong but this is possible to define in your .podspec. So I don't see the need to add this ability at this time.

For question 2: I played around with this and could not get CocoaPods to not overwrite the .xcconfig files to use. I extracted some settings and set it in the source .pbxproj, made sure that it got picked up, but when I try to consume it, CocoaPods would replace them with the generated ones. The only options I see here is to either 1) modify the final .pbxproj to use the supplied ones and #include the .xcconfig files generated by Pods or 2) #include the supplied .xcconfig files in the generated ones. In either case, we would have to implement a pod post-install script that would do this, and make sure that it will work with each upgrade of either CocoaPods or Xcode.

In the long run, I'm not sure this is worth the effort. react-native-test-app use default settings for pretty much everything. It is a test app, to be consumed by frameworks/libraries that need one. It is not intended to be checked in. It is hidden from view on disk, and will get wiped away with git clean.

Now, going back to the PR that started this conversation, I don't believe that this issue should be a blocker to merge microsoft/fluentui-react-native#302.

@HeyImChris, what are your thoughts?

I agree that 1 seems unnecessary to me. For 2, what I'm not sure about is what the difference is between extracting config settings here https://github.com/microsoft/fluentui-react-native/tree/master/apps/ios/src and doing so in this test app we're in now. The project in FLURN doesn't need a post install step, you need to generate the pod xcconfigs and then include them similar to how it's done here. Is the problem with our consumption of this test app that causes the config settings to get lost?

from react-native-test-app.

Sorry, I took another look and it seems I missed a few things while rushing through it. 😛 CocoaPods will only overwrite base configuration if the files are missing. I had of course forgotten to copy them over.

I have a draft PR out. My current concern is that we have to modify our .xcconfig to #include the configuration files generated by CocoaPods. I have hard coded the paths for now but this seems very flaky to me. @alloy, I've tagged you on the relevant lines. Would love to hear if you have a better solution.

from react-native-test-app.

🎉 This issue has been resolved in version 0.1.22 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from react-native-test-app.

🎉 This issue has been resolved in version 0.1.24 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from react-native-test-app.