某些库根据目标平台的不同而不一致地公开函数和类型。特别是libc和nix做到了这一点。如何在配置时检测到crate是否提供了某些功能（如libc::mmap64或libc::posix_fallocate）？我知道我不能基于库导出的常量值#[cfg()]，库也不能向用户导出配置选项。我想我必须使用build.rs来检测它，但我不确定如何检测。
libc
nix
libc::mmap64
libc::posix_fallocate
#[cfg()]
build.rs
mm5n2pyu1#
RFC #2523指定了一个符号#[cfg(accessible(path))]，它可以用来做一些你想要的事情（以及其他事情）：#[cfg(accessible(libc::mmap64))]只有在libc::mmap64()可以访问时才会打开。然而，这个RFC目前还没有完全实现。也就是说，由于技术上的困难，#[cfg(accessible)]的部分不是。然而，PR #69870实现了类似的东西：#[cfg_accessible(path)]。然而，根据我的测试，我不确定它是否真的适用于这种情况，而且，它不能与cfg操作结合使用-这意味着例如。它不能被否定：你不能实现一些逻辑，当某些东西 * 是 * 不可用。因此，最好的办法是为实现此功能的平台选择#[cfg()]。这是每个人都在做的事。
#[cfg(accessible(path))]
#[cfg(accessible(libc::mmap64))]
libc::mmap64()
#[cfg(accessible)]
#[cfg_accessible(path)]
1条答案
按热度按时间mm5n2pyu1#
RFC #2523指定了一个符号
#[cfg(accessible(path))]，它可以用来做一些你想要的事情（以及其他事情）：#[cfg(accessible(libc::mmap64))]只有在libc::mmap64()可以访问时才会打开。然而，这个RFC目前还没有完全实现。也就是说，由于技术上的困难，
#[cfg(accessible)]的部分不是。然而，PR #69870实现了类似的东西：
#[cfg_accessible(path)]。然而，根据我的测试，我不确定它是否真的适用于这种情况，而且，它不能与cfg操作结合使用-这意味着例如。它不能被否定：你不能实现一些逻辑，当某些东西 * 是 * 不可用。
因此，最好的办法是为实现此功能的平台选择
#[cfg()]。这是每个人都在做的事。