'really' invalidating caches , EAP and 1.6.4

I've been chasing a bug (my bad) whereby one of my textures that i thought had been updated was not updating in the .app package. So , went through the routine of invalidating caches , clean, build ... no use. Just to be sure, did the same with 1.6.4.  Same result.  I finally track down your caches on disk, and discover that 'invalidate caches' does not actually invalidate them !!! the files (old) were still on disk in the caches. If that process had worked as i would expect it dit, i would have saved a lot of time.

Next question : what would happen if i scrapped by hand the directory ? Will AppCode quitely recreate the directory structure without complaint ?

/Users/yvesleborg/Library/Caches/appCode10/DerivedData
/Users/yvesleborg/Library/Caches/appCode20/DerivedData

instead of going through that  bogus menu AND restart ?

2 comments
Comment actions Permalink

Invalidate caches doesn't do output cleaning, it only resets internal AppCode's caches.
There is a request to implement 'Clean DerivedDir Folder' action, that we plan to implement in 2.0: http://youtrack.jetbrains.com/issue/OC-2601

0
Comment actions Permalink

by the tracking number, this does not seem like a priority item :) ... anyways, i tried the rm -R method, worked fine, AppCode recreated DerivedData (correctly cleaned) at the next build.

0

Please sign in to leave a comment.