OSX .app bundle generated in release/ and .dmg has timestamp of assets/osx/Alacritty.app dir

[dnwe]

When building a new release of Alacritty, the .app bundle has the modification timestamp of the assets folder in git (assets/osx/Alacritty.app) rather than the time of the build.

i.e., from a brand new checkout make dmg you end up with:

$ ls -ld /Volumes/Alacritty/Alacritty.app /Volumes/Alacritty/Alacritty.app/Contents/MacOS/alacritty
drwxr-xr-x  3 user  staff      102 12 Mar  2018 /Volumes/Alacritty/Alacritty.app/
-rwxr-xr-x  1 user  staff  6632008 29 Oct 16:51 /Volumes/Alacritty/Alacritty.app/Contents/MacOS/alacritty

Ideally the .app bundle timestamp would match the build timestamp.

[chrisduerr]

That's because it's the last modification timestamp of the directory.

I'm not quite sure here what the desired behavior would accomplish.

[dnwe]

@chrisduerr yes I understand, but an .app bundle on OSX is visually a single item. When opening up the dmg and copying to /Applications it is unusual for the .app to appear to be six months old for a release that was only released and built a few days ago.

[chrisduerr]

If it's displayed incorrectly in macOS, that seems like an OSX issue.

However you could always just touch -m file to update the date if that is important to you.

[dnwe]

@chrisduerr no? it's the alacritty Makefile that preserves the timestamps when copying the template dir
https://github.com/jwilm/alacritty/blob/master/Makefile#L35

[chrisduerr]

You could still update the timestamp by using touch -m file after it has been moved. Alternatively it's also possible to exclude the timestamp from the -p option of cp.

[dnwe]

Yep, these are the things I currently do on each build. This GH issue is to suggest making that the behaviour of the Makefile so builds are correct out of the box.

[chrisduerr]

Feel free to open a PR to introduce this change.