java.io.File.renameTo() deletes any existing file with the new name on most systems, but there is no guarantee and no exception is thrown. We just get a "return false" from the native file system if it doesn't do the rename.
renameTo is used to finalise the names of xtc compile task outputs, and since the output directory is populated through a SourceTask and Sync, it should always be the case that any existing output gets replaced if the task has to be re-run.
However, to avoid bug reports if something is wrong with the state or the way the build was invoked, I've added code that tries to delete any existing destination file before the rename. I'm not 100% sure that this is better than keeping the current behavior, but with a better error message, because it shouldn't really happen if you build the XDK, incrementally or otherwise, with ./gradlew build from the root. And gradle clean will sort it, should it happen.
java.io.File.renameTo() deletes any existing file with the new name on most systems, but there is no guarantee and no exception is thrown. We just get a "return false" from the native file system if it doesn't do the rename.
renameTo is used to finalise the names of xtc compile task outputs, and since the output directory is populated through a SourceTask and Sync, it should always be the case that any existing output gets replaced if the task has to be re-run.
However, to avoid bug reports if something is wrong with the state or the way the build was invoked, I've added code that tries to delete any existing destination file before the rename. I'm not 100% sure that this is better than keeping the current behavior, but with a better error message, because it shouldn't really happen if you build the XDK, incrementally or otherwise, with ./gradlew build from the root. And gradle clean will sort it, should it happen.