Re: How to detect the configuration?
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