[Project] Remove automatic preprocessor macro named after configuration

[mrackwitz]

This addresses #4143.

CocoaPods extended the original Xcodeproj behavior when adding a new configuration. A preprocessor definition named after the newly created configuration was automatically configured. This was done to support the TargetEnvironmentHeader specification of Pods available only on certain build configurations. The TargetEnvironmentHeader was removed meanwhile, but that was left.

Note:

This has potential to break a lot of pods for debugging, especially those which have relied on the DEBUG=1 definition.

Agreement:

DEBUG=1 should be kept, additionally all other configuration macros should be prefixed by POD_CONFIGURATION_

[segiddins]

I'm not convinced we can get rid of the DEBUG define without breaking lots of pods.

[segiddins]

Changes are fine if we decide the change in behavior is what we want

[mrackwitz]

Yes, we should try to make a well-thought-out decision on that. If we decide against, which would be reasonable, I would update instead just the comment accordingly.

For most cases, this will mean that neither DEBUG nor RELEASE for the according configuration will be defined. Podspecs can't take care of defining these macros as the xcconfigs attributes are not configuration(-type) dependent. This will make it hard to define the macro as user from the podfile, you will likely need to add a post_install hook. It is not enough to define the macro in the user project, when the pod makes use of the macro in the implementation files.

An alternative could be to use a less conflict-prone name for the macro, e.g. COCOAPODS_CONFIG_DEBUG. This can be still aliased to other names using the pod_target_xcconfig or headers.

/c @CocoaPods/core

[neonichu]

I would say, let's break it now and move to a COCOAPODS_ prefixed variant instead.

[orta]

I'm not entirely sure I get this change, can someone ELI5 for me? 👼

[neonichu]

@orta TIL ELI5 :)

CP automatically generates preprocessor defines named after the build configurations right now, e.g. DEBUG. These can clash with other uses of the same name in user projects, as described in #4143.

This PR removes those preprocessor defines completely, but as it is hard to replicate their existence manually, there would also be the possibility of renaming them to something less likely to cause naming clashes. In any case, if we change this, Pods that rely on the defines for conditional compilation will break.

[segiddins]

Thinking more about this, I don't think it's a good idea to get rid of the DEBUG define, since Xcode generates it by default in debug mode... I think, ultimately, this is trying to fix a bit of an edge case. If a project truly wants to have a variable named DEBUG, they can #undef it?

[mrackwitz]

I'd agree for DEBUG at least, especially as Xcode sets it by default.
For the other configurations, I could still imagine that we define them only with a namespacing, which I would apply back to the debug configuration for consistency.

[segiddins]

I don't think the other configurations are strictly necessary, but if its something like POD_CONFIGURATION_FOO, I wouldn't object to it 👍

[segiddins]

Scoping for 1.0, as this is a breaking change.

[segiddins]

I have an implementation of this locally, will push up tonight.

[segiddins]

This has been succeeded by #4702.