Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Overwriting xcconfig files. #523

Closed
ErikEvenson opened this Issue Sep 17, 2012 · 14 comments

Comments

Projects
None yet
7 participants

Currently, pod install overwrites the configurations set if an Xcode project is already using .xcconfig files to manage its configuration.

I would suggest adding an option that lets the user include the Pods.xcconfig file rather than to silently overwrite the existing information. Something like:

#include "Pods.xcconfig"

Also, make sure the configuration settings append to rather than rewrite any configuration settings.

I see issue #482 is a similar issue.

Owner

fabiopelosin commented Sep 17, 2012

I would suggest adding an option that lets the user include the Pods.xcconfig file rather than to silently overwrite the existing information.

I think that if there is already an xcconfig we can just print a message that tells the user to include it in his own config like in 482. This is usually done only once because we integrate the user project only once.

Also, make sure the configuration settings append to rather than rewrite any configuration settings.

We just set the pods.xcconfig file, we don't override anything else. So it is unclear to me what do you mean.

We just set the pods.xcconfig file, we don't override anything else. So it is unclear to me what do you mean.

For example, the Pods.xcconfig file has the line HEADER_SEARCH_PATHS = ${PODS_HEADERS_SEARCH_PATHS}. Won't this override any header search paths I might have previously selected?

Owner

fabiopelosin commented Sep 18, 2012

I see your point. So I think that the best solution would be to add $(inherited) to all the flags of the Pods.xcconfig and during integration still set the Pods.xcconfig and if there was already an xcconfig specified for the target import it via #include.

What do you think?

So I think that the best solution would be to add $(inherited) to all the flags of the Pods.xcconfig

Yeah, I concur.

during integration still set the Pods.xcconfig and if there was already an xcconfig specified for the target import it via #include

I wonder if the order of xcconfig files will matter. Would it be better to add a #include "Pods/Pods.xcconfig" in the existing xcconfig file instead? That way, the developer can see where Pods.xcconfig is being imported within the code that they have written. This would seems more in line with the idea that the project is the parent and the pods are children.

Owner

fabiopelosin commented Sep 18, 2012

I wonder if the order of xcconfig files will matter. Would it be better to add a #include "Pods/Pods.xcconfig" in the existing xcconfig file instead?

In this case I think that we would just print a message informing the user to add #include "Pods/Pods.xcconfig" manually. Editing directly the xcconfig might be error prone.

That way, the developer can see where Pods.xcconfig is being imported within the code that they have written. This would seems more in line with the idea that the project is the parent and the pods are children.

Good points. I think that the disadvantage is that it would be necessary to specify $(inherited) for any flag that could override the Pods.xcconfig. However, I'm not sure if adding the import at the end of the existing xcconfig would work.

I would guess adding the include at the end would work. Seems to with the config files I use.

Owner

alloy commented Sep 21, 2012

I might not have followed along correctly, but I would like to point out that afaik $(inhertited) does not work for settings defined in multiple xcconfig files.

@ghost ghost assigned fabiopelosin Oct 23, 2012

Any update here? Running into the same problem.

I ran into the same problem. It's not difficult to include the Pods.xcconfig in your own setup, but finding out by CocoaPods having broken the build by changing the base configuration for your targets isn't the nicest way.

Owner

fabiopelosin commented Mar 13, 2013

@mbaltaks Which version of CocoaPods are you using. I thought that the check was already implemented. Regarding the possibility to include your Xcconfig I think that the setup described in #833 should work.

@irrationalfab The version appears to be 0.16.3 - I'm new to ruby so rvm and bundler are still slightly confusing for me, it's actually quite different to virtualenv and pip from python. I see that this version is some weeks old, but that's what gem install provided me last week.

All I ended up doing was undoing the project changes that were made by cocoapods, and simply including the Pods.xcconfig in my target base xcconfig files. I don't need to adjust settings in the pods themselves as in #833.

jzapater pushed a commit to jzapater/CocoaPods that referenced this issue Sep 17, 2013

Merge pull request #523 from matzew/master
Adding new AeroGear version to the repo
Contributor

kylef commented Mar 11, 2014

Closing (duplicate of #1736).

@kylef kylef closed this Mar 11, 2014

gardner commented Jun 3, 2014

@kylef There are a myriad of issues which talk about build settings. This issue is distinct from #1736. Please see @alloy's comment above and reopen this issue. I have been reading through countless bugs that are closed as "Just add $(inherited)...". Please see @alloy's comment above and reopen this issue or at least close it as a duplicate of an issue which actually represents the same issue. Also, generally, the newer bug is closed as "duplicate of" when there are duplicates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment