Platify
Platify streamlines cross-platform Rust development by removing the boilerplate associated with #[cfg(...)] attributes.
Instead of cluttering your code with repetitive checks and manual dispatch logic, Platify allows you to define platform-specific behavior using a clean, declarative attribute syntax.
Features
#[sys_function]: Automatically dispatches method calls to platform-specific implementations (e.g.,fn run()->fn run_impl()).#[sys_trait_function]: Applies platform configuration to methods within a trait definition.#[sys_struct]: Generates platform-specific type aliases (e.g.,MyStruct->MyStructLinux) and verifies trait implementations at compile time.#[platform_mod]: Declares modules backed by OS-specific files (e.g.,linux.rs,windows.rs) with strict visibility control.- Smart Logic: Supports explicit
includeandexcludelists. - Group Keywords: Use helpers like
posix(Linux + macOS) orall.
Installation
Add this to your Cargo.toml:
[]
= "0.2.0"
Or run:
Usage
1. Platform-Dependent Functions (#[sys_function])
This macro generates a default method that delegates the call to a suffixed implementation (e.g., _impl). It automatically applies the correct #[cfg] guards based on your configuration.
use sys_function;
;
// Implementation details (usually handled in separate files or cfg blocks)
2. Platform-Specific Struct Aliases & Checks (#[sys_struct])
This macro does two things:
- Creates type aliases for platform-specific builds (e.g.,
HandleWindows). - Verifies that the struct implements specific traits (like
SendorSync) at compile time. This is crucial for FFI wrappers where thread-safety is easily accidentally broken.
use sys_struct;
// 1. Generates `HandleWindows` alias on Windows.
// 2. Asserts at compile time that `Handle` implements `Send` and `Sync`.
// This works even with generics!
// Generated code roughly looks like:
//
// #[cfg(target_os = "windows")]
// pub type HandleWindows<T> = Handle<T>;
//
// #[cfg(target_os = "windows")]
// const _: () = { ... assert T: Send + Sync ... };
3. Trait Definitions (#[sys_trait_function])
Allows you to define methods in a trait that are only available on specific platforms.
use sys_trait_function;
4. Platform-Dependent Modules (#[platform_mod])
Maps a logical module to a platform-specific file (e.g., mod driver maps to linux.rs or windows.rs).
Visibility Logic: This macro separates internal convenience from external access:
- External: The specific module (e.g.,
linux) inherits the visibility you declared (pub), so users must importcrate::linux::Device. - Internal: The logical alias (
driver) is generated as private, ensuring your internal code remains generic while forcing external users to be explicit about platform dependencies.
// Expects src/linux.rs and src/windows.rs to exist.
// --- Internal Usage ---
// Inside this file, we use the generic private alias.
Consumer Usage (External Crate):
// Error: 'driver' is private.
// use my_crate::driver::Device;
// Correct: The platform module is public.
use Device;
Configuration Logic
You can control which platforms are targeted using include(...) and exclude(...).
| Keyword | Description |
|---|---|
linux |
Target Linux (target_os = "linux") |
windows |
Target Windows (target_os = "windows") |
macos |
Target macOS (target_os = "macos") |
posix |
Expands to linux and macos |
all |
Expands to linux, macos, and windows |
How it is calculated
- Start: If
includeis present, start with that set. If omitted, start withall. - Filter: Remove any platforms specified in
exclude. - Result: The macro generates
#[cfg(any(target_os = "..."))]for the remaining platforms.
Examples
include(linux)→ Only Linux.exclude(windows)→ Linux + macOS.include(posix), exclude(macos)→ Only Linux.
License
This project is licensed under the MIT License - see the LICENSE file for details.