build.rs: copy i10n in release #8276
Conversation
|
some jobs are failing |
| source_path, dest_path, err | ||
| ); | ||
| } else { | ||
| println!( |
There was a problem hiding this comment.
Where does this println output to?
Its reflected when used with cargo -vv like
[coreutils 0.1.0] cargo:rerun-if-changed=build.rs
[coreutils 0.1.0] cargo:rustc-cfg=build="release"
[coreutils 0.1.0] Copied locale file: /home/sudhackar/repos/coreutils/src/uu/base32/locales/en-US.ftl -> /home/sudhackar/repos/coreutils/target/release/locales/base32/en-US.ftl
[coreutils 0.1.0] Copied locale file: /home/sudhackar/repos/coreutils/src/uu/base64/locales/en-US.ftl -> /home/sudhackar/repos/coreutils/target/release/locales/base64/en-US.ftl
[coreutils 0.1.0] Copied locale file: /home/sudhackar/repos/coreutils/src/uu/basename/locales/en-US.ftl -> /home/sudhackar/repos/coreutils/target/release/locales/basename/en-US.ftl
[coreutils 0.1.0] Copied locale file: /home/sudhackar/repos/coreutils/src/uu/basename/locales/fr-FR.ftl -> /home/sudhackar/repos/coreutils/target/release/locales/basename/fr-FR.ftl
....
|
GNU testsuite comparison: |
|
@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: |
|
GNU testsuite comparison: |
- works the same in both release and debug
|
GNU testsuite comparison: |
|
@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. 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 |
|
GNU testsuite comparison: |
Discussed in #8263.
Only l10n that are configured for the build get their l10n files copied to the
target/releasedirectory.CLI works as intended in release.