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

Check exit status only in Build::is_flag_supported #790

Closed
wants to merge 2 commits into from
Closed

Check exit status only in Build::is_flag_supported #790

wants to merge 2 commits into from

Conversation

NobodyXu
Copy link
Collaborator

@NobodyXu NobodyXu commented Feb 8, 2023

This commit/PR enables warnings_into_errors, which causes the compiler to fail if there is any warning unless user override them by specifying env variable CFLAGS or CXXFLAGS.

Thus we no longer need to check stderr for warnings and can now only check exit status of the compiler.

This commit also fixed the fn reset_env in tests/test.rs to use std::env::remove_var instead of std::env::set_env($var, "").

This commit/PR is done according to the advice from @mqudsi in #784 (comment)

Signed-off-by: Jiahao XU [email protected]

This commit/PR enables warnings_into_errors, which causes the compiler
to fail if there is any warning unless user override them by
specifying env variable `CFLAGS` or `CXXFLAGS`.

Thus we no longer need to check stderr for warnings and can now only
check exit status of the compiler.

This commit also fixed the fn `reset_env` in `tests/test.rs` to use
`std::env::remove_var` instead of `std::env::set_env($var, "")`.

This commit/PR is done according to the advice from @mqudsi in
#784 (comment)

Signed-off-by: Jiahao XU <[email protected]>
Comment on lines +546 to +549
cmd.arg(&src)
.stdin(Stdio::null())
.stdout(Stdio::null())
.stderr(Stdio::null());
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we inherit stdout and stderr?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I believe we should not, since stdout and stderr is for messages from compiler when building the project.
Build::is_flag_supported does not build the project but only test the flags, so I think the stdout and stderr should be piped to null.

Copy link
Contributor

Choose a reason for hiding this comment

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

But we don't provide any other mechanism for the developer to check why a test failed, unlike other build systems that write the output of all these checks/tests to a log file.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But we don't provide any other mechanism for the developer to check why a test failed, unlike other build systems that write the output of all these checks/tests to a log file.

Ehh that's true, I can set that to inherit but I think the stdout/stderr might be a little bit confusing to users.
If that's fine, then I can remove these lines.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let’s wait for another opinion? That was just my two cents.

@thomcc
Copy link
Member

thomcc commented Feb 10, 2023

I'm not sure about this. I'm pretty sure there's a reason the current code was the way it was... I'll have to go looking.

@mqudsi
Copy link
Contributor

mqudsi commented Feb 10, 2023

I had done some git spelunking when I was looking into #784 and found that it was just originally added as "execute and check if stderr is empty" to see if the presence of the flag caused any errors or warnings (you can't just check stderr in that case because the presence of an unrecognized flag/switch would trigger a warning but not an error). Later @NobodyXu added the exit code check in #757 but without any other changes and without a motivating bug (I don't think it changed the behavior in any way since "exit code is 0" is probably a strict subset of "stderr is empty").

If you're not using -Werror then checking the stderr is required, but if you're using -Werror then checking the stderr is overkill because it necessitates workarounds like

https://github.com/rust-lang/cc-rs/blob/0d9a0f84e43fdb3eef34ff9726f7cb915a2b619a/src/lib.rs#L515C9-L519

which is only needed because stderr may sometimes contain non-error output (because no one says otherwise).

src/lib.rs Outdated Show resolved Hide resolved
@mqudsi
Copy link
Contributor

mqudsi commented Feb 10, 2023

I've been rethinking what I said in #784, and I'm not sure using CFLAGS and CXXFLAGS is necessarily the right approach. If a user has an invalid flag in CFLAGS, that means every is_flag_supported() call will fail/return false (this is the current behavior).

Signed-off-by: Jiahao XU <[email protected]>
@NobodyXu
Copy link
Collaborator Author

Hmmm I think it's better to check stderr just to be sure that the flag is indeed supported and there might be cases where the flag is just ignored and compiler exits with success.

@NobodyXu NobodyXu closed this Jul 20, 2023
@NobodyXu NobodyXu deleted the simplify-is_flag_supported branch July 20, 2023 05:19
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.

3 participants