[xtqqczze]

USe cfg-aliases crate for selinux and smack features.

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/date/resolution. tests/date/resolution is passing on 'main'. Maybe you have to rebase?
GNU test failed: tests/rm/isatty. tests/rm/isatty is passing on 'main'. Maybe you have to rebase?
GNU test failed: tests/tail/retry. tests/tail/retry is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Note: The gnu test tests/cp/link-heap is now being skipped but was previously passing.
Note: The gnu test tests/printf/printf-surprise is now being skipped but was previously passing.

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/date/date-locale-hour is no longer failing!
Note: The gnu test tests/cp/link-heap is now being skipped but was previously passing.
Note: The gnu test tests/dd/no-allocate is now being skipped but was previously passing.
Note: The gnu test tests/seq/seq-epipe is now being skipped but was previously passing.
Note: The gnu test tests/tail/pipe-f is now being skipped but was previously passing.

[github-actions]

GNU testsuite comparison:

Note: The gnu test tests/cut/cut-huge-range is now being skipped but was previously passing.

[sylvestre]

sorry
i really don't like the duplication of src/uu/*/build.rs

[xtqqczze]

I don’t like the duplication either, but I’m not sure how to avoid it. Do you have suggestions on how we could factor this out?

[sylvestre]

i prefer the current state than this duplication, sorry

[xtqqczze]

I guess we could include!("../../common/common_cfg.rs") in each build.rs?

[sylvestre]

if it works, it would be better

[xtqqczze]

I've tried specifying the cfg in .cargo/config.toml but it doesn't support expressions like all(...) or any(...).

The only alternative I can think of is introducing a small common_cfg helper crate to centralize the cfg_aliases logic, but that feels a bit heavy-handed.

[xtqqczze]

I guess we could include!("../../common/common_cfg.rs") in each build.rs?

@sylvestre If this works, would you approve the changes?

[oech3]

Cannot we use workespace's toplevel build.rs?

[sylvestre]

Cannot we use workespace's toplevel build.rs?

i don't think it works. i tried too and failed

[sylvestre]

I guess we could include!("../../../common/common_cfg.rs") in each build.rs?

@sylvestre If this works, would you approve the changes?

yes
thanks

[xtqqczze]

I guess we could include!("../../common/common_cfg.rs") in each build.rs?

Annoyingly, this didn't work.

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/cp/cp-a-selinux. tests/cp/cp-a-selinux is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/inotify-dir-recreate (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/cut/bounded-memory (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/pr/bounded-memory (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/cp/link-heap is now being skipped but was previously passing.
Note: The gnu test tests/env/env-signal-handler was skipped on 'main' but is now failing.

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/cp/cp-a-selinux. tests/cp/cp-a-selinux is passing on 'main'. Maybe you have to rebase?
Note: The gnu test tests/cut/cut-huge-range is now being skipped but was previously passing.

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/cp/cp-a-selinux. tests/cp/cp-a-selinux is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/cut/bounded-memory (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/tail/pipe-f is now passing!

[oech3]

I don't like symlink since it breaks tarball extraction on Windows, but can you symlink build.rs?

[xtqqczze]

I don't like symlink since it breaks tarball extraction on Windows, but can you symlink build.rs?

Can't do this because some utilities already have a build.rs.

[xtqqczze]

@sylvestre Actually, I don't think we should move the alias definitions to a common location. They depend on features defined by each crate (e.g. selinux), so a shared definition would have to assume those features exist everywhere. That would couple the common layer to crate-specific feature names.

[oech3]

@zicklag Is there any way to share one config given by cfg_aliases at workspace?

[zicklag]

Oh, that's a great question! I need to double-check the way that cargo handles the custom cfgs before I know for sure.

You might be able to just put the cfg aliases in a crate that is included in all your other crates and they might be inherited, but I haven't verified yet.

If that doesn't work then it would be reasonable to add a feature to cfg_aliases specifically for that.

I'll try to test it out today and let you know.

[xtqqczze]

I guess we could include!("../../common/common_cfg.rs") in each build.rs?

This actually works, but rust-analyzer has an issue and shows a macro error: rust-lang/rust-analyzer#20129

@zicklag When I last looked into this, that approach turned out to be non-viable due to a rust-analyzer issue.

[zicklag]

Oh, interesting.

I just confirmed that the cfgs are not inherited from dependencies' build scripts ( which makes sense, otherwise there could be namespacing issues ).

I'll experiment with options and share what I find.

[zicklag]

OK, I think I found something that works pretty nicely.

In your workspace you can create a file like cfgs.rs:

pub fn activate() {
    cfg_aliases::cfg_aliases! {
        sixtyfour: { target_arch = "x86_64" },
        thirtytwo: { target_arch = "x86" }
    }
}

Then in each crate that will need to use the aliases you can do this in the build.rs:

#[path = "../cfgs.rs"]
mod cfgs;

fn main() {
    cfgs::activate();
}

Rust analyzer seems happy with it for me.

Let me know if that doesn't work for you for some reason. 🫡

[xtqqczze]

@zicklag Thanks! That approach worked well. As a first step, I’ve opened #15634.

[xtqqczze]

Depends on #15634.

[xtqqczze]

@zicklag With your approach, I occasionally encounter a rust-analyzer E0583 error:

unresolved module, can't find module file: ../../../cfg_aliases.rs

However, as described in rust-lang/rust-analyzer#20129, this can be worked around by explicitly adding the file to rust-analyzer's VFS includes:

"rust-analyzer.vfs.extraIncludes": ["${workspaceFolder}/cfg_aliases.rs"]