Project Assistant renames home folder without authorisation Re: define GCC_PREFIX_FILE setting at project level?
Project Assistant renames home folder without authorisation Re: define GCC_PREFIX_FILE setting at project level?
- Subject: Project Assistant renames home folder without authorisation Re: define GCC_PREFIX_FILE setting at project level?
- From: Rua Haszard Morris <email@hidden>
- Date: Tue, 20 Jun 2006 09:56:02 +1200
Wow this thread woke up!
My update is that yes it does work at the project level, I have
changed my template project (hacking the pbxproj, naturally) by
moving the GCC_PREFIX_HEADER setting from the target level to the
project level, reinstantiated the template via the assistant, and C++
code compiled as if the prefix file was working.
I'm surprised that prefix files cause trouble for others... my
relevant settings are the file itself (a relative path to it), at
project level, and "precompile prefix header" at target level. I've
pasted the build configurations section for the template project
below in case it's helpful to anyone.
I have another beef with the project assistant however: a .DS_Store
file was in my template folder, so when the template is instantiated
it asks "Do you want to overwrite DS_Store" (with a very busy and
confusing dialog). So I overwrote it, because clearly I never cared a
bit about this particular file (it's now deleted from the template
folder).
What happened next was a shock - it moved the original destination
folder aside (by renaming it) presumably so I could recover my
previous .DS_Store if need be (aargh). This was really bad because I
was creating the project in my home folder (as a sandpit, away from
the real source tree), and the project assistant had renamed my home
folder. As you could expect, this caused some serious issues with the
rest of the system; e.g. Mail.app thought that all my email was "not
available while offline" etc.
So I've managed to move my real home folder back now - but I had to
sudo, why could the project assistant do it without getting
permission? If this isn't a security hole it's definitely a usability
hole!
Anyway, my project template is working nicely now...
cheers,
Rua HM.
4FADC23408B4156C00ABE55E /* Debug */ = {
isa = XCBuildConfiguration;
buildSettings = {
COPY_PHASE_STRIP = NO;
GCC_DYNAMIC_NO_PIC = NO;
GCC_ENABLE_FIX_AND_CONTINUE = YES;
GCC_MODEL_TUNING = G5;
GCC_OPTIMIZATION_LEVEL = 0;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
INSTALL_PATH = "$(HOME)/Library/Bundles";
PRODUCT_NAME = "«PROJECTNAME»(6)";
WRAPPER_EXTENSION = bundle;
ZERO_LINK = YES;
};
name = Debug;
};
4FADC23508B4156C00ABE55E /* Release */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = (
ppc,
i386,
);
GCC_GENERATE_DEBUGGING_SYMBOLS = NO;
GCC_MODEL_TUNING = G5;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
INSTALL_PATH = "$(HOME)/Library/Bundles";
PRODUCT_NAME = "«PROJECTNAME»(6)";
WRAPPER_EXTENSION = bundle;
};
name = Release;
};
4FADC23808B4156C00ABE55E /* Debug */ = {
isa = XCBuildConfiguration;
baseConfigurationReference = 9390D2320A42633600EE7BC1 /*
ADICrossDevelop.xcconfig */;
buildSettings = {
DEAD_CODE_STRIPPING = YES;
EXPORTED_SYMBOLS_FILE = ../../LibraryADI/ExtensionInterfaces/
Main1.exp;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
GENERATE_PKGINFO_FILE = YES;
INFOPLIST_FILE = ../«PROJECTNAME»/Info.plist;
PREBINDING = NO;
PRESERVE_DEAD_CODE_INITS_AND_TERMS = YES;
GCC_PREFIX_HEADER = ../../../Common/PrefixFiles/
ADICarbonDebug_Prefix.h;
REZ_PREFIX_FILE = ../../../Common/PrefixFiles/
ADIXcodeDebug_Prefix.r;
HEADER_SEARCH_PATHS =
(
../../Common/OEMIncludes,
"$(SDKROOT_$(CURRENT_ARCH))/Developer/Headers/FlatCarbon",
);
REZ_SEARCH_PATHS = (
../../LibraryADI/ExtensionInterfaces/,
../../../Common/OEMIncludes,
);
USER_HEADER_SEARCH_PATHS = "../../../Common/p2cLibs ../../../
Common/MacToolBoxExtras ../../../Common/LibraryCommon";
};
name = Debug;
};
4FADC23908B4156C00ABE55E /* Release */ = {
isa = XCBuildConfiguration;
baseConfigurationReference = 9390D2320A42633600EE7BC1 /*
ADICrossDevelop.xcconfig */;
buildSettings = {
DEAD_CODE_STRIPPING = YES;
EXPORTED_SYMBOLS_FILE = ../../LibraryADI/ExtensionInterfaces/
Main1.exp;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
GENERATE_PKGINFO_FILE = YES;
INFOPLIST_FILE = ../«PROJECTNAME»/Info.plist;
PREBINDING = NO;
PRESERVE_DEAD_CODE_INITS_AND_TERMS = YES;
GCC_PREFIX_HEADER = ../../../Common/PrefixFiles/
ADICarbonRelease_Prefix.h;
REZ_PREFIX_FILE = ../../../Common/PrefixFiles/
ADIXcodeRelease_Prefix.r;
HEADER_SEARCH_PATHS =
(
../../Common/OEMIncludes,
"$(SDKROOT_$(CURRENT_ARCH))/Developer/Headers/FlatCarbon",
);
REZ_SEARCH_PATHS = (
../../LibraryADI/ExtensionInterfaces/,
../../../Common/OEMIncludes,
);
USER_HEADER_SEARCH_PATHS = "../../../Common/p2cLibs ../../../
Common/MacToolBoxExtras ../../../Common/LibraryCommon";
};
name = Release;
};
On 20/06/2006, at 9:15 AM, Matt Neuburg wrote:
On Sun, 18 Jun 2006 20:33:58 -0700, Chris Hanson <email@hidden> said:
On Jun 18, 2006, at 3:57 PM, Rua Haszard Morris wrote:
I was hoping to be able to set GCC_PREFIX_FILE at the project build
settings level (and not have GCC_PREFIX_FILE set at target level)
but found the prefix file was not being used.
I don't think there is a setting called GCC_PREFIX_FILE. You may be
thinking
of GCC_PREFIX_HEADER.
Xcode fails to set $PREFIX_HEADER. This is a known bug. I'm
impressed that
you were able to get prefix headers to work at all (see the
archives, under
the thread "say, what happened to prefix files?"). I still can't
get them to
work (without explicitly setting GCC_PREFIX_HEADER to the name of
the PCH).
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
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