Re: How to detect the configuration?
Re: How to detect the configuration?
- Subject: Re: How to detect the configuration?
- From: Brian Stern <email@hidden>
- Date: Thu, 29 May 2008 14:48:42 -0400
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.
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.
--
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