Skip to content
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

Expose Pods-environment header to the user project #1068

Closed
dtorres opened this issue May 25, 2013 · 6 comments
Closed

Expose Pods-environment header to the user project #1068

dtorres opened this issue May 25, 2013 · 6 comments
Labels
s2:confirmed Issues that have been confirmed by a CocoaPods contributor t1:enhancement Enhancements that have not been picked up yet. Please comment if you plan to work on it

Comments

@dtorres
Copy link
Contributor

dtorres commented May 25, 2013

I'm developing for different environments that differ in their Pods
Say, beta contains remote logging and production (App Store) doesn't.

To selectively disable their implementations I check for the constants defined in Pods-environment.h but I can't reach it from the target project.

Should I copy it as you have to with the Acknowledgements or I'm just doing it wrong?

@alloy
Copy link
Member

alloy commented May 26, 2013

For now you should add it to your own project as well indeed. Atm it’s mainly meant for pods to know which other pods have been enabled.

@irrationalfab Do we want to expose this to the user by default?

@fabiopelosin
Copy link
Member

I think that exposing it might be helpful. However I'm not sure what benefit it could provide over #731.

@dtorres
Copy link
Contributor Author

dtorres commented May 27, 2013

Exposing it is useful and is different than #731 because I'm targeting features based on the availability of the pods.

I do not have different build/targets in Xcode but instead built a script in ruby that allows me to setup environments.

So, I usually do this
'POD_ENV=beta pod update'
That for example sets the normal pods plus TestflightSDK.

Another thing it does is setup several API_KEYs for that environment but that's beyond cocoa pods I guess.

Sent from my iPhone

On May 27, 2013, at 2:41, Fabio Pelosin notifications@github.com wrote:

I think that exposing it might be helpful. However I'm not sure what benefit it could provide over #731.


Reply to this email directly or view it on GitHub.

@angelolloqui
Copy link
Contributor

I am also interested on having this Pods-environment.h exposed to the client app. In my case I am making a generic app that will be available in multiple forms, so of them including some optional pods while some others dont. Having this macro helps a lot because I can do conditional imports and code based on the existance of the pod instead of having to deal with things on runtime or by some other complex scripts.

jzapater pushed a commit to jzapater/CocoaPods that referenced this issue Sep 17, 2013
[Update] AKTabBarController (1.0)
@dtorres dtorres assigned CocoaPodsBot and unassigned CocoaPodsBot Mar 29, 2014
@CocoaPodsBot
Copy link

Issue has been confirmed by @neonichu

@kylef
Copy link
Contributor

kylef commented Sep 14, 2014

I don't think you need this header to do this. Instead use __has_include:

#if __has_include("QueryKit.h")
#import "QueryKit.h"
#endif

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s2:confirmed Issues that have been confirmed by a CocoaPods contributor t1:enhancement Enhancements that have not been picked up yet. Please comment if you plan to work on it
Projects
None yet
Development

No branches or pull requests

6 participants