Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix build.rs: Use env::var_os to retrieve Path #1580

Merged
merged 5 commits into from
Oct 6, 2023

Conversation

NobodyXu
Copy link
Contributor

  • Fix retrieveing OUT_DIR in build.rs
  • Fix getting CARGO_MANIFEST_DIR: Use env::var_os
  • Modify run_command_with_args to take OsStr instead of String for args
  • Call env::var_os in read_env_var
  • Change return type to PathBuf instead of String for fn compile

Signed-off-by: Jiahao XU Jiahao_XU@outlook.com

@briansmith
Copy link
Owner

Is the entire purpose of this PR to support non-Unicode(-compatible) paths? Is there any other goal with this PR?

@briansmith
Copy link
Owner

I agree with the idea that we should be using OsStrings for paths. Do you have a realistic example of a configuration that works with this PR but doesn't work without this PR, so I can understand the real-world implications better? Thanks in advance!

@NobodyXu
Copy link
Contributor Author

Is the entire purpose of this PR to support non-Unicode(-compatible) paths? Is there any other goal with this PR?

Yes

I agree with the idea that we should be using OsStrings for paths. Do you have a realistic example of a configuration that works with this PR but doesn't work without this PR, so I can understand the real-world implications better? Thanks in advance!

Linux filename can be anything that is \0 terminated and various unix program accepts anything that is ascii-compatible, that is, encoded in bytes and can use all ascii characters.

So the user can use arbitary non-unicode characters in their home dir or whatever dir, cargo new --lib . a project, then add this project as a dependency and tries to cargo b it.

Without non-unicode support, this will fail since the CARGO_MANIFEST_DIR is likely to be a absolute path.
It is also possible that OUR_DIR is a absolute path and even if it's not, the user could change the location and name of the target dir.

So it's possible for these environment variables to contain non-unicode and I'd like ring's build.rs to properly handle it.

@briansmith
Copy link
Owner

Linux filename can be anything that is \0 terminated and various unix program accepts anything that is ascii-compatible, that is, encoded in bytes and can use all ascii characters.

That is true, but if somebody is taking full advantage of that flexibility, it's really their own fault.

Without non-unicode support, this will fail since the CARGO_MANIFEST_DIR is likely to be a absolute path.

I understand. I'm simply asking could you provide a plausible scenerio where CARGO_MANIFEST_DIR contains non-Unicode-compatible characters? For example, "If a user with username "X" tries to build ring when their system character set is Y then the build fails." I.e. something I could test out myself without feeling silly.

@NobodyXu
Copy link
Contributor Author

NobodyXu commented Feb 17, 2023

I understand. I'm simply asking could you provide a plausible scenerio where CARGO_MANIFEST_DIR contains non-Unicode-compatible characters? For example, "If a user with username "X" tries to build ring when their system character set is Y then the build fails." I.e. something I could test out myself without feeling silly.

On linux, I am able to create a non-unicode dir by running:

mkdir $(printf '\xFF')

And then cd into it by running:

cd $(printf '\xFF')

I can create a user with non-unicode home:

adduser a --home /home/"$(printf 'a\xFF')"

and cd into it:

cd /home/"$(printf 'a\xFF')"

@briansmith
Copy link
Owner

@NobodyXu Is this an issue that's causing trouble on a real system, or just a theoretical issue? 0xFF in a path is a theoretical issue. This will help me prioritize this.

@NobodyXu
Copy link
Contributor Author

@NobodyXu Is this an issue that's causing trouble on a real system, or just a theoretical issue? 0xFF in a path is a theoretical issue. This will help me prioritize this.

Unfortunately I don't have any real world example for this, so right now it just stays as a theoretical issue, but I won't be surprised if somebody out there is having non-unicode path in their system, hence I think it's better to support any Path.

Copy link
Owner

@briansmith briansmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PTAL at #1698. Your changes here are more thorough #1698. I think it would be great if you could review #1698 and then rebase this on that. If you do I will review it and merge it right away.

build.rs Outdated
}

fn main() {
const RING_PREGENERATE_ASM: &str = "RING_PREGENERATE_ASM";
match read_env_var(RING_PREGENERATE_ASM).as_deref() {
Ok("1") => {
Some(val) if val == OsStr::new("1") => {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can do Some(val) if val == "1"; see #1698.

build.rs Outdated
@@ -692,9 +689,10 @@ fn nasm(file: &Path, arch: &str, include_dir: &Path, out_file: &Path) -> Command
c
}

fn run_command_with_args<S>(command_name: S, args: &[String])
fn run_command_with_args<S, Arg>(command_name: S, args: impl IntoIterator<Item = Arg>)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just get rid of the generics here; see #1698.

Use `env::var_os` instead of `env::var` to handle non utf-8 path
correctly.

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Do not convert `Path`/`OsStr` to `String` in `cc`, instead creates an
`OsString` and push to it.

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
@NobodyXu
Copy link
Contributor Author

NobodyXu commented Oct 6, 2023

@briansmith I've rebased this PR against main, please review this.

Copy link
Owner

@briansmith briansmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for doing this. If you have other things you want to clean up in build.rs I would be happy to work with you on them. PR #1699 is another one you may be interested in.

target: &Target,
include_dir: &Path,
out_dir: &Path,
) -> PathBuf {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

out_file.to_str().expect("Invalid path")
))
.arg(file);
let _ = c.arg("-c").arg(arg).arg(file);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also very nice.

@codecov
Copy link

codecov bot commented Oct 6, 2023

Codecov Report

Merging #1580 (dd3d803) into main (244a1de) will decrease coverage by 0.01%.
Report is 4 commits behind head on main.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1580      +/-   ##
==========================================
- Coverage   95.99%   95.98%   -0.01%     
==========================================
  Files         134      134              
  Lines       19980    19980              
  Branches      199      199              
==========================================
- Hits        19179    19178       -1     
  Misses        765      765              
- Partials       36       37       +1     

see 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@briansmith briansmith merged commit 2e06558 into briansmith:main Oct 6, 2023
139 of 140 checks passed
@briansmith
Copy link
Owner

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants