Incremental compilation

I wonderwhat are the rules applied by compiler.


I have a class with gesture recognizers that I define programmatically (none in IB).

As I suspected this to be the cause of some error, I commented out all the addGestureRecognizer.


After compiling the error was still there, but the gestures wre still recognized, just as if my changes had been ignored.


I did a build clean, recompiled and then the gestures were effectively disabled.


I draw the conclusion that to be sure of what is compiled we're better off to option clean before. Am I right ?

Answered by KMT in 281212022

If you mean wait and then do it before building, generally, yes, that works for me and is now my habit.


What I did when I started doing option-clean was to use it often until I learned where it was needed/had an effect as a routine vs. not needed at all. New code, no, vs. changes/edits to existing code, certain build settings, code signing, yes, including image/asset names, which I've learned not to juggle inside Xcode.


Xcode has always loved to hold on to indexed code/assets like a dog w/a bone - seems like a design feature to speed work by letting Xcode favor old data over new, but it seems to accomplish the opposite by building distrust and making more work in the end where the dev starts making more and more changes, not knowing why they don't have a visible effect in a new build. Sort of like how Safari favors it's caches to make things go faster.


Doing a simple clean is rarely useful. We're told a simple clean empties that target's derived data folder/indexed data, where an option-clean deletes the entire build folder for that project. Doesn't seem to have the desired effect tho, so I no longer bother with it.

Accepted Answer

If you mean wait and then do it before building, generally, yes, that works for me and is now my habit.


What I did when I started doing option-clean was to use it often until I learned where it was needed/had an effect as a routine vs. not needed at all. New code, no, vs. changes/edits to existing code, certain build settings, code signing, yes, including image/asset names, which I've learned not to juggle inside Xcode.


Xcode has always loved to hold on to indexed code/assets like a dog w/a bone - seems like a design feature to speed work by letting Xcode favor old data over new, but it seems to accomplish the opposite by building distrust and making more work in the end where the dev starts making more and more changes, not knowing why they don't have a visible effect in a new build. Sort of like how Safari favors it's caches to make things go faster.


Doing a simple clean is rarely useful. We're told a simple clean empties that target's derived data folder/indexed data, where an option-clean deletes the entire build folder for that project. Doesn't seem to have the desired effect tho, so I no longer bother with it.

Incremental compilation
 
 
Q