• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: How to detect the configuration?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to detect the configuration?


  • Subject: Re: How to detect the configuration?
  • From: Scott Tooker <email@hidden>
  • Date: Thu, 29 May 2008 13:40:05 -0700


On May 29, 2008, at 11:48 AM, Brian Stern wrote:


On May 29, 2008, at 2:16 PM, Chris Espinosa wrote:

On May 29, 2008, at 10:54 AM, Brian Stern wrote:

On May 29, 2008, at 12:48 PM, Clark Cox wrote:

On Thu, May 29, 2008 at 5:05 AM, Richard Kennaway
<email@hidden> wrote:
How can an XCode program detect whether it was built in Debug or Release
configuration (or any other, for that matter)? In Visual Studio, _DEBUG is
defined as a preprocessor symbol for Debug versions, but I can't find
anything similar in the project settings in XCode, or the docs. I can
manually add _DEBUG to the settings, but that's tedious in a project with a
dozen build targets. Is there anything automatically #defined?

There is no need to add it to a dozen build targets. Add it to the project, and it will be inherited by all of the targets in said project.

The whole point of DEBUG/RELEASE macros is that some build configurations #define one and the rest #define the other. It wouldn't make sense to #define DEBUG for all the build configurations in a project (at least not to me).

He meant "define it for the Debug configuration at the project level," which is exactly the right thing to do.

OK Fair enough. I still don't understand this.

I'd strongly encourage you to read the section on build settings in the Xcode User Guide. There's no denying that the current system of targets and configurations (with settings at the target and project level) is complex, but it's also very powerful and expressive.




That's because a) they started that way and b) it was a homogenous community. With the diversity of sources of Mac OS X software (Classic, Carbon, Cocoa, BSD, etc.) we've researched several times the utility of imposing a predefined DEBUG macro on all projects, and have always come to the same conclusion:

- any macro common enough to be useful has the risk of breaking somebody's project with a conflict or by introducing unexpected behavior
- any macro uncommon enough to be safe won't benefit anybody out of the box; people will generally have to define DEBUG=$ (XCODE_DEBUG_CONFIGURATION) or some such.


At that point it's just as much work for everybody to define their own preferred debug macro in their own idiom, and more intuitive. In the future should we change the build system in a substantial way so that a change like this is in the noise, we definitely want to do something like this.

But it's not a retroactive change. It's only for new projects. It won't break anything or introduce anything different than not having the macros but kind-of sort-of implying that they're there by having predefined DEBUG/RELEASE build configurations. I have a hard time understanding how predefining DEBUG/NDEBUG in new project templates in the obvious way would break projects in unexpected ways. I think that 90% of developers would like this and the rest wouldn't care.


While I use DEBUG/NDEBUG I don't really care what macro Xcode introduces. I think it is easy for me to add

#if defined(XCODE_DEBUG_CONFIGURATION_DEBUG)
#define DEBUG 1
#else
#define NDEBUG 1
#endif

to my PCH file to get the macro definitions that I want and much more effort to have to go through the project settings to add this to the build configurations. Further, in time Mac developers will adopt whatever macro Xcode settles on. You or Carbon/Cocoa/BSD could also provide header files that include this sort of boilerplate for use by those projects that require it. So simply an

#include <Cocoa/CocoaDebugSettings.h> could be added to the PCH file if desired and that would be that.

Obviously I'm not changing anyone's opinion but I really don't understand the thinking here.

For brand new code in brand new projects, the inclusion of some basic macros probably wouldn't be such a big deal. However, consider the following cases:


- pre-existing code base moved into a new project
- regenerating an older existing project from a  new project template
- merging/tearing apart older projects into new projects

All these cases bring with them legacy codebases that may already be using well-established macro conventions.

In addition, if the the workaround is as simple to go to the project setting's Debug configuration and add DEBUG=1 to "Preprocessor Macros" (and RELEASE=1 in the Release configuration), I'd rather have the developer do the explicit change and be aware of the macros rather than have someone get bit indirectly by a macro they didn't realize was in effect.

Scott




--
Brian Stern
email@hidden



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Thanks for the warm invite! (From: Fred Gaddis <email@hidden>)
 >Re: Thanks for the warm invite! (From: "Michael Crawford" <email@hidden>)
 >Re: Thanks for the warm invite! (From: Jens Alfke <email@hidden>)
 >Re: Thanks for the warm invite! (From: "Michael Crawford" <email@hidden>)
 >How to detect the configuration? (From: Richard Kennaway <email@hidden>)
 >Re: How to detect the configuration? (From: "Clark Cox" <email@hidden>)
 >Re: How to detect the configuration? (From: Brian Stern <email@hidden>)
 >Re: How to detect the configuration? (From: Chris Espinosa <email@hidden>)
 >Re: How to detect the configuration? (From: Brian Stern <email@hidden>)

  • Prev by Date: libxml2.dylib
  • Next by Date: Re: Default Parent Directory for New Projects
  • Previous by thread: Re: How to detect the configuration?
  • Next by thread: Re: How to detect the configuration?
  • Index(es):
    • Date
    • Thread