Conditional proc-macros

[FlorianDevPhynix]

The library I'm working on, has the requirement of being able to be used by rust and non-rust users.

I didn't like the idea of creating a separate crate in the project just as a wrapper for my main library, so I created a proc-macro crate that makes the safe-ffi macros conditional based on a feature flag.

It seems to work well because the file size of the outputs decreases drastically. The ".a" file goes from 26,3 MiB to 25,7 MiB and the ".rlib" file from 641,7 KiB to 51,8 KiB.

This seems like a improvement to me, but it could also be that this would not make any difference to the library users. The Rust compiler could just remove this unneeded code, when it's not used.

use proc_macro::TokenStream;
use syn::parse_macro_input;

#[proc_macro_attribute]
pub fn ffi_export (
    attrs: TokenStream,
    input: TokenStream,
) -> TokenStream
{
    parse_macro_input!(attrs as syn::parse::Nothing);
    if cfg!(feature = "ffi_compile") {
        format!("#[::safer_ffi::ffi_export]\n{}", input).parse().unwrap()
    } else {
        input
    }
}

#[proc_macro_attribute]
pub fn derive_ReprC (
    attrs: TokenStream,
    input: TokenStream,
) -> TokenStream
{
    //eprintln!("attrs: \"{}\"", attrs);
    if cfg!(feature = "ffi_compile") {
        format!("#[::safer_ffi::derive_ReprC]\n#[repr({})]\n{}", attrs, input).parse().unwrap()
    } else {
        input
    }
}

[features]
default = ["headers"]
headers = ["safer-ffi/headers", "ffi_compile"]
ffi_compile = ["safer-ffi-deactivate/ffi_compile"]

[danielhenrymantilla]

Yeah, this is both a legitimate question, and also something a bit "contrived" to be featuring inside safer-ffi itself (it's basically asking for there to be an opt-out to "disable" the whole crate).

One thing I could do, then, is to basically officialize and publish your safer-ffi-deactivate wrapper crate, since I really see a wrapper crate as the best place to do this kind of conditional replacement with dummy macros.

Maybe named as safer-ffi-toggler?

[FlorianDevPhynix]

Sounds like a great idea. I've continued working on my library and realized that methods are not supported. Wrapper functions will be needed for those but I think that, whether or not go for a separate wrapper crate, is a decision that everyone will have to make themselves. So having this separate seems great. Especially because we could maybe add some great helper macros.