Stream: general

Topic: cfgs as public API?

nagisa (Dec 29 2018 at 17:18, on Zulip):

I have a problem of needing to essentially provide a cfg-bool as a public API of a library. So far the only solution that comes to mind is to have a macro that spits out tokens provided certain cfgs were set, but that is very inconvenient to implement and not obvious to use.

nagisa (Dec 29 2018 at 17:18, on Zulip):

do we have any better solutions?

pnkfelix (Jan 31 2019 at 12:42, on Zulip):

I'm trying to understand what you mean by a "cfg-bool"? Is the intent to export a value that can somehow be used within attributes or other expansion-time constructs?

pnkfelix (Jan 31 2019 at 12:43, on Zulip):

Or is this just a single value that you want to be used as something that would act like #[cfg(bool)] depending on some internal function of various cfg's it sees?

nagisa (Jan 31 2019 at 13:04, on Zulip):

Well, the problem I’m trying to solve is as follows: certain functions simply do not exist for targets A, B and C.

nagisa (Jan 31 2019 at 13:04, on Zulip):

internally within the library I have the cfgs that I work based on. Those are generated by the build script.

nagisa (Jan 31 2019 at 13:05, on Zulip):

Now how do I export that information to those targets so that they could decide whether to use the functions or implement some sort of a fallback.

nagisa (Jan 31 2019 at 13:06, on Zulip):

What I have so far is this (within my library)

macro_rules with_function_a { (($tree: tt)*) => { } }
macro_rules! with_function_a { (($tree: tt)*) => { $($tree)* } }

(and also similarly negative variant with_not_function_a) which is ugly and otherwise inconvenient.

nagisa (Jan 31 2019 at 13:07, on Zulip):

I would much rather just make the function_a_exsists cfg a part of my public API.

Last update: Jan 20 2020 at 20:50UTC