I agree that there is a lot of wasted time and energy, though having two separate ways to build the library has its own maintenance overhead. Would you be interested in proposing a PR to improve on the status quo along the lines you suggested?

@djc So something along the lines of this?

#![allow(non_camel_case_types, clippy::unreadable_literal)]

#[cfg(feature = "timezone-filter")]
include!(concat!(env!("OUT_DIR"), "/timezones.rs"));

#[cfg(not(feature = "timezone-filter"))]
include!("prebuilt_timezones.rs");

I'm not sure by the way whether this would be considered a breaking change or not. It means that without setting the timezone-filter feature you would suddenly not get a filtered set of timezones anymore making your binary bigger, but I believe anyone depending on chrono-tz would continue to work as you'll only get more functionality than you asked for.

I also believe we need to pin a specific version of phf, because any bumps to its version could potentially invalidate the pre-built mapping otherwise.

Arguably this is already broken in chrono-tz today. I don't believe there is anything in-place to ensure the version of phf matches that of phf_codegen exactly, which is not a problem today but if 0.12 comes out it could become a problem if embedded in a program that pins phf to 0.11 but nothing pinning phf_codegen or vice versa.

@djc So something along the lines of this?

#![allow(non_camel_case_types, clippy::unreadable_literal)]

#[cfg(feature = "timezone-filter")]
include!(concat!(env!("OUT_DIR"), "/timezones.rs"));

#[cfg(not(feature = "timezone-filter"))]
include!("prebuilt_timezones.rs");

Yes, something like this seems reasonable.

I'm not sure by the way whether this would be considered a breaking change or not. It means that without setting the timezone-filter feature you would suddenly not get a filtered set of timezones anymore making your binary bigger, but I believe anyone depending on chrono-tz would continue to work as you'll only get more functionality than you asked for.

One the one hand, it feels not great when users who have explicitly enabled features that will limit their binary size implicitly loose that optimization in a semver-compatible upgrade. On the other hand, they're probably in the (tiny) minority and so making life better for everyone else without having them opt-in to the improvement might still make sense?

I also believe we need to pin a specific version of phf, because any bumps to its version could potentially invalidate the pre-built mapping otherwise.

Pinning a specific version sounds like a non-starter to me, but I also don't exactly see why it's necessary?

@djc Unless I misunderstand something, for them to work correctly the phf and phf_codegen crate must match exactly in version. If you don't specify a specific version it's possible due to other crates that they diverge. For example:

Crate `chrono-tz`
    phf = "^0.11"
    phf_codegen = "^0.11"

Crate `foo`
    phf = "=0.11.0"

In this scenario the crate resolver might choose 0.11.0 for phf and 0.11.1 for phf_codegen. I suppose we could simply trust the phf folks not to introduce internal algorithm changes to the PHF in minor versions that would break stuff, but technically speaking semver allows such a thing.

I think trusting the phf maintainers is probably the best option here, yes.