Some crates should expose indirect axhal as a direct optional dependency to compile on multiple platforms

[zjp-CN]

For crates that transively/indirectly rely on axhal, there is no way to compile them on non-host targets/platforms, like axfs:

arceos/modules/axfs $ cargo b --target aarch64-unknown-none-softfloat
   Compiling axhal v0.2.0 (/home/gh-zjp-CN/arceos/arceos/modules/axhal)
error[E0463]: can't find crate for `axplat_aarch64_qemu_virt`
  --> modules/axhal/src/lib.rs:48:9
   |
48 |         extern crate axplat_aarch64_qemu_virt;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

For more information about this error, try `rustc --explain E0463`.
error: could not compile `axhal` (lib) due to 1 previous error

The solution is to add optional axhal in axfs's Cargo.toml, and compile with -Faxhal/defplat

[dependencies]
+axhal = { workspace = true, optional = true }

arceos/modules/axfs $ cargo b --target aarch64-unknown-none-softfloat -Faxhal/defplat 

[zjp-CN]

To identify if the crate needs the dependency pattern, besides compiling itself, cargo tree can be utilized to know if axhal is transitive:

arceos/modules/axdisplay $ cargo tree --target aarch64-unknown-none-softfloat -i axhal -e normal
axhal v0.2.0 (arceos/modules/axhal)
├── axdriver v0.2.0 (arceos/modules/axdriver)
│   └── axdisplay v0.2.0 (arceos/modules/axdisplay)
└── axtask v0.2.0 (arceos/modules/axtask)
    └── axsync v0.2.0 (arceos/modules/axsync)
        └── axdisplay v0.2.0 (arceos/modules/axdisplay)

If axhal doesn't have direct node with current crate in the inverse dependency tree, the crate has the problem.

# After the fix (with -Faxhal to include axhal)
arceos/modules/axdisplay $ cargo tree --target aarch64-unknown-none-softfloat -i axhal -e normal -Faxhal
axhal v0.2.0 (arceos/modules/axhal)
├── axdisplay v0.2.0 (arceos/modules/axdisplay) 👈 direct dependency
├── axdriver v0.2.0 (arceos/modules/axdriver)
│   └── axdisplay v0.2.0 (arceos/modules/axdisplay)
└── axtask v0.2.0 (arceos/modules/axtask)
    └── axsync v0.2.0 (arceos/modules/axsync)
        └── axdisplay v0.2.0 (arceos/modules/axdisplay)

NOTE: If the crate owns direct dependency like axfeat or axstd that wraps axhal's defplat feature, it's unnecessary to have the fix, because axfeat/defplat and axstd/defplat are identical as axhal/defplat.

[equation314]

Yes, to cross-compile axfs, you must also compile axhal. However, it's not recommended to add axhal as a dependency to axfs, as it won't be used directly within axfs. You can use the following command:

cargo build -p axfs -p axhal --target aarch64-unknown-none-softfloat --features defplat

[zjp-CN]

Oh, that's great! I didn't expect that will work, especially that defplat are auto-detected for packages:

# defplat is appropriately applied to axhal and axstd in the dependency graph
arceos $ cargo build -p axfs -p axhal -p axstd --target aarch64-unknown-none-softfloat --features defplat
# Same for the feature alloc which is only applied to axstd
arceos $ cargo build -p axfs -p axhal -p axstd --target aarch64-unknown-none-softfloat --features defplat,alloc

by comparison, this doesn't work:

arceos ✗ cargo b -p axfs --target aarch64-unknown-none-softfloat --features defplat
error: the package 'axfs' does not contain this feature: defplat
help: packages with the missing feature: axhal, axfeat, axstd, axlibc

---

That's the intended behavior of Cargo resolver = "2" :

With version "1", cargo build -p bar --features bar-feat would fail because the --features flag only allowed enabling features on foo.
With resolver = "2", the features flags allow enabling features for any of the packages selected on the command-line with -p and --workspace flags.

---

But the reason to have individual crate successfully compiled is that os-checker will jump in each crate to run the checking command, instead of building from the root of workspace. Sometimes that's the only way to compile member crates, like this one.

Axhal really needs mutually-excusive & global features to work.

On the other hand, if axfs and similar crates mentioned in the fix PR will be published on crates.io, it's weird for them to be unable to cross-compile without adding axhal back in user's crate, even though the crate doesn't use axhal directly.

[equation314]

axfs contains many ArceOS-specific designs, and we don't plan to release it to crates.io in the short term. It's recommended to keep it as it is now.