uutils
build.rs: copy i10n in release
Discussed in #8263.
Only l10n that are configured for the build get their l10n files copied to the target/release directory.
CLI works as intended in release.
GNU testsuite comparison:
Skip an intermittent issue tests/misc/tee (fails in this run but passes in the 'main' branch)
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@sylvestre will do. However I would like to point out that the jobs don't seem to fail due to the new code but the code that was here beforehand. I also wonder if it makes sense to have a completely different approach to handling localization files based on the build profile. If we take this approach with build.rs in release, I would think it would be completely fine to make it the same for debug builds. Please have a look at get_locales_dir. To me it seems like a complexity we can and should avoid.
GNU testsuite comparison:
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/misc/stdbuf (passes in this run but fails in the 'main' branch)
GNU testsuite comparison:
Skip an intermittent issue tests/misc/tee (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)
GNU testsuite comparison:
Skipping an intermittent issue tests/misc/tee (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/timeout/timeout (passes in this run but fails in the 'main' branch)
@sylvestre, I tried making the localization the same across build profiles but it seems like that breaks quite a lot of tests. I reverted those changes and only keeping this scoped, maybe we can have a look some other time. build.rs does not support tests by default, is it acceptable to add a new package that is going to be a build-dependency and have tested code that is going to be used in build.rs?
EDIT: Looking at the tests that failed before revert, there might be something that I'm missing with the current implementation. Investigating...
EDIT: Seems that the cause of failure for the tests when we have a unified approach is due to Rust using non-standard binary paths when runnings tests (starting from deps making it unable to find relative locales path). It's best that we keep the distinction between debug and release.
GNU testsuite comparison:
Skip an intermittent issue tests/misc/tee (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/timeout/timeout (passes in this run but fails in the 'main' branch)
GNU testsuite comparison:
Skip an intermittent issue tests/misc/stdbuf (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)
GNU testsuite comparison:
GNU test failed: tests/du/threshold. tests/du/threshold is passing on 'main'. Maybe you have to rebase?
GNU test failed: tests/factor/factor. tests/factor/factor is passing on 'main'. Maybe you have to rebase?
GNU test failed: tests/misc/comm. tests/misc/comm is passing on 'main'. Maybe you have to rebase?
GNU test failed: tests/mv/mv-exchange. tests/mv/mv-exchange is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/misc/tee (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/misc/usage_vs_getopt (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)