I’m testing some project as a Neko target and it seems that replacing some image on the /Assets folder doesn’t replace the image on the already existing Export assets folder.
I’ve made a couple of tests and it seems that it only replaces the image if the date on the Export file is older.
I’m not sure if that is a design decision (I think I’d rather get the assets replaced if I did that on my Assets folder), but the problem here is that the date on the Export folder is not that of the original file, but the date the file was copied there, so even though I could have replaced my file for a newer one on /Assets, if that file was created before the original file was cpoied to Export, it won’t get copied.
System: OSX 10.9.5
Here’s my haxelib list:
hxcpp: [3.1.39]
hxlibc: [1.1.4]
hxtools: [1.1.6]
lime-tools: 1.3.2 [1.5.7]
lime: 0.9.6 1.0.1 2.0.0-alpha.7 2.0.0-alpha.8 [2.0.0-beta]
openfl-native: 1.3.0 [1.4.0]
openfl: 1.3.0 [2.1.5]
I believe I have looked extensively, but Haxe does not have a good cross-platform method for setting the file modified time and date. As a result, having it reflect when it was copied is more reliable, and about what we can expect for now.
Some projects have a LOT of assets – one I know has GBs worth. By not copying assets unless they have been changed, it helps speed up builds a lot, and reduce unnecessary disk usage. I suppose, however, the most reliable method would be something that would keep a manifest of which files it found and copied, and then the copy would occur if the file’s time and date was different than the manifest recorded. I’m not sure where that file would be saved out to, but that would be one solution.
Now if you save a new copy, or copy in a different version, doesn’t it also set the date to that moment, or how are you swapping the assets? Are you doing it only based on the source path in XML, with various pre-existing asset versions?
You can obviously do a “-clean” build, though that currently dumps the compiler cache as well
In FlashDevelop, you could set up a pre-build script that deletes the assets in the Export folder.
If you’re using an HXP project, you could do the same in an IDE-independent way. Though if you do, make sure the command is BUILD or TEST. (Otherwise, it would attempt to delete the files every single time you used the compiler’s code completion.)
Come to think of it, “openfl update” is used for live asset reloading, which you surely would not want to copy every file, every time, so open to ideas for improvement, but we’ve got to do something that will try to sync changes rather than overwrite each time
It was not a big issue for me (I manually deleted the exported file). I just noticed it and I thought it was something that could be corrected.
I guess that you normally replace assets with newer versions, but I think there are many other times where you might want to restore or use assets that might have an older date.
I think that any change I make on the assets folder should be reflected on the export folder (deletes don’t work either).
I’m not an OpenFL expert and its build system so I don’t think I could help with ideas on how to improve it 
