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@hiddenhttp://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
