|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Chris Hanson wrote: >> Is it not smart enough to know that they haven't changed? > >Xcode should understand what has and hasn't changed and know what >should and shouldn't need to be rebuilt if the dependencies are set up >and a shared build directory is being used. If it doesn't do this >properly, it's a bug. Although 2.2 is better, I still get the odd occasion where Xcode suddenly decides that everything needs to be rebuilt, or doesn't rebuild the files it should when something in a sub-sub-sub-project is touched, etc. Logging these in Radar is quite frustrating, as there's no obvious way to reproduce them or understand why it's doing what it's doing (I suspect it's just as frustrating to try and fix :-). Is there any way to force Xcode to dump out the decisions it makes during dependency analysis, to capture why something needs to be built (or not)? E.g., a list of each source/header file visited, the actual timestamp on disk vs the timestamp from the last build, the things each file depends on, which one caused it to be flagged as dirty, etc. I appreciate that list will get pretty big on larger projects, but I'd be happy to leave that log rewriting itself in /tmp if it meant I could log a bug showing exactly where it went wrong. -dair ___________________________________________________ mailto:email@hidden http://www.zonic.co.uk/ _______________________________________________ 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
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.