Tidying on external_deps#1992
Conversation
|
I forgot to say may the smart_copy commit also unifies the used copy options (and avoids some GNUism). |
| } | ||
|
|
||
| smart_copy() { | ||
| if ! cp --reflink=auto -P "${@}" 2>/dev/null |
There was a problem hiding this comment.
As of GNU cp 9.x which is a few years old --reflink=auto is the default. So this is unnecessary.
There was a problem hiding this comment.
We better be picky, and we still build the game and its external deps on Debian Bullseye which has coreutils 8.32-4+b1 anyway.
| cd "${dir_name}" | ||
| cp -r include/* "${PREFIX}/include" | ||
| cp -r lib/* "${PREFIX}/lib" | ||
| smart_copy -R 'include/.' "${PREFIX}/include/" |
There was a problem hiding this comment.
It copies all the content of the folder without globbing (and, even if it's not needed there, it likely copies hidden files too, that globbing may misses).
If you copy dir to dir you may end up with dir/dir, while by coyping dir/. to dir/., you make sure only the content get copied.
That's because . is “self”, and doesn't have any name, and one cannot create . in a folder, it's non-ambiguous.
Edit: And dir/./. is dir/. wichi is dir/ so by copying . into dir/. even if you may be copying . into dir/. and get dir/./., then dir/./. is still dir/…
There was a problem hiding this comment.
OK I looked it up and it's a trick to get the same behavior from GNU and BSD cp.
Seems doubtful that we actually want dot files (e.g. Mac .DS_Store), but ones more than one level down would be copied anyway so at least it's consistent?
There was a problem hiding this comment.
Seems doubtful that we actually want dot files (e.g. Mac
.DS_Store), but ones more than one level down would be copied anyway so at least it's consistent?
Yes, it makes things consistent. If we need to filter-out .DS_Store, we better hunt for them than to rely on implicit behaviors.
2 participants
Tidying on external_deps.
Extracted from:
The unify style commit is just bikeshedding, it's just to be consistent within the file (not claiming that new files should do it that way), so later code I already wrote will also be consistent
The rewriting comment commit is also just bikeshedding, but future architecture implementations (already written) will match that wording.
The smart_copy commit is useful as it uses copy-on-write enabled cp when available (much faster copy because data is not duplicated on disk). The copy-on-write enabled cp already knows how to do a standard copy when the feature is not provided by the filesystem, the test to fallback on the standard cp tool on systems like macOS.
Some commits rewrite the way things are copied, in better way (for example to avoid globbing when unneeded).
In some cases, it actually fixes a bug where a folder is copied in itself the second time the script is run. This only applied to a software we don't package yet (WASI), but letter have this ready for the day we continue this effort.
The EXE_EXT thing will reduce diff noise when future code will land.
The xz compression stuff should be obvious, it's just an extra option to make the compression more extreme.
We don't have to wait for more meaningful changes to merge that, and it makes my branch smaller.