Allow the user to customize the prefix headers and the xcconfigs

[orta]

See this thread for some context: http://stackoverflow.com/questions/12967220/i-want-to-allow-invalid-ssl-certificates-with-afnetworking

Essentially we should be able to declare in the podfile that I want pods to run with some other c flags that can manipulate the pod libraries themselves.

---

Renamed from:Add an ability to apply #defines to pods target from podfile

[fabiopelosin]

I have been held back to implement this feature because I believe that configurations should be set up in the runtime instead of using macros. However as there are cases in which this setup makes sense, I think that we should support this feature it.

I am of the opinion that the best way to implement this feature is to create a header for each Pod library imported at the end of its prefix header. This file should be created only if doesn't exits and should never be overwritten by CocoaPods as it would be under the user control. I think that would be a more manageable solution rather than adding some sort of DSL to the Podfile.

The only open question, for me, is where to store this file as the Pods should not be kept under source control. We could have a Pods/User and Pods/Generated structure. Note that we need to make some changes the structure of the Pods folder after 0.17 as it is getting messy (there is an issue somewhere).

[alloy]

@irrationalfab +1

Regarding the Pods directory, it’s indeed time for another clean-up, your suggestions sound good, we could then also start telling people to keep external specs in Pods/User/Specs, or something along those lines.

[fabiopelosin]

This setup should also generate xcconfigs. Maybe we could also generate xcconfigs for the user targets which imports the Pods xcconfig so the users have the last say on the build settings.

[smazurov]

I have to 👍 whatever solution to this might be, because it seems often than not you have to do something special for the Pods to make them play nice with your project. Having ability to overwrite and include extra stuff in the Pods-prefix.pch is invaluable. config.project_pods_root going away in 0.17 would make that release currently impossible to use.

The only solution I can come up with is ether a custom .podspec file that just has a bunch of s.prefix_header_path declarations that do what we want, or maintaining our own versions of .podspec files for the dependancies that need "monkey patching" to work how we want them to.

I also hope that having a special directory under Pods/ isn't the solution as that breaks the Pods-in-SCM rule like you were mentioning.

Anyways, this is just my 2 cents on the issue.

[fabiopelosin]

@smazurov

config.project_pods_root going away in 0.17 would make that release currently impossible to use.

The access to the config has been deprecated in order to preserve the needed flexibility for our private interfaces. I'm assuming that you need this information in the post-install hook of the Podfile where the InstallerRepresentation#sandbox_root is available. Isn't this suitable for your needs?

I also hope that having a special directory under Pods/ isn't the solution as that breaks the Pods-in-SCM rule like you were mentioning.

We plan to move all the generated content (everything in the Pods folder at the moment) in the Pods/Generated (please tell me if you come up with a better name) folder and that would be the one which should be kept under version control.

[orta]

This is an interesting approach to getting around this issue: #891

[rromanchuk]

👍

[bachand]

@irrationalfab With the recent deprecation of LibraryRepresentation::prefix_header_path and LibraryRepresentation::prefix_header_filename, what is the preferred way to manually modify the Pods .pch file during post_install (until another solution is devised). As you mentioned above InstallerRepresentation::sandbox_root is available, but I'd prefer to not have to hardcode the .pch file name unless I have to...

[alloy]

@bachand You can use the prefix_header_contents or prefix_header_file attributes.

[bachand]

I'm trying to modify the .pch file in a Podfile's post_install hook, not a Specification's post_install hook. Since I'm not dealing with a Specification directly, I don't think those attributes are available, though I could be missing something.

[rromanchuk]

same as @bachand +1

[fabiopelosin]

@bachand & @rromanchuk Sorry about this issue, I didn't consider the usage from the Podfile while introducing the warning. This deprecated method is not going to be removed before this issue is implemented. For this reason, if the warning is not an issue for you, you can keep relying on it. If you would like to avoid the warning in the meanwhile you can use:

installer_representation.installer.libraries.map(&:prefix_header_path)

Please see library/#prefix_header_path for more information.

[bachand]

Got it, thanks @irrationalfab!

[fabiopelosin]

After some discussion we conclude that the best approach is to have a single public (user editable) prefix header for all the aggregate targets (target definitions) and for all the Pods targets.

Regarding xccofings there should be a public one per each aggregate target.

[alloy]

Agreed.

[fabiopelosin]

Note: the user should have the possibility to just restore one user configurable file to the empty state as generated by CocoaPods simply deleting it.

[fabiopelosin]

After some discussion we conclude that the best approach is to have a single public (user editable) prefix header for all the aggregate targets (target definitions) and for all the Pods targets.
Regarding xccofings there should be a public one per each aggregate target.

However we could also implement a system where we create one per target by default and then we have a naming convention and if the user creates one because he needs to configure just a single Pod, it is detected and used by the next pod install

/c @alloy

[mogui]

what's the state of this issue?, there's a way to include macro o redefine constants for a library?

[CocoaPodsBot]

Issue has been confirmed by @neonichu

[tychop]

A lot of people have the problem where settings defined on PROJECT LEVEL are not inherited by cocoapods in its xcconfig file.

That really needs to be fixed. I need to set Linker Flags and header search paths on project level so it can get inherited by all of my targets. Currently, because Pods.xcconfig doen not inherit them I must specify this information on all of my targets which is not a good way of doing that.

[gardner]

This is terrible on large projects. We have many targets and configurations which means ~30 xcconfig files. To start using CocoaPods on this project we need to rearrange everything in our xcconfig files manually.

It seems like CocoPods should be able to work with existing xcconfig files. The safest way to augment the existing xcconfig files would be to walk down the #include xcconfig files until finding one that sets a variable (e.g. OTHER_LDFLAGS) which also does not include any other files. Then append $(PODS_OTHER_LDFLAGS) to the line.

[segiddins]

With the advent of frameworks, I'm really not sure we need to implement this beyond the already-supported post-install hooks.

[neonichu]

Also does anything keep people from setting their own XCConfig in the project and including the one created by CP? They'd get a warning when doing a pod install, but that's about it or am I missing something?

[segiddins]

They won't even get the warning any more, if they actually include the CocoaPods one.

[neonichu]

And prefix headers should 🔥 anyways - I'd also say this is not relevant anymore.

[batrinuvlad]

What's the solution to this after all?
I mean I've been trying to inject some code in all .pch files using the post_install hook, but no success https://stackoverflow.com/questions/58522119/inject-code-in-pch-files-from-pods-in-post-install