log's build.rs file is very simple. It just checks the target platform and then tells Cargo to pass in --cfg=atomic_cas and/or --cfg=has_atomics as necessary. Those conditions are then used in about 10 different places, all in src/lib.rs.

This use of build.rs is understandable. It's the only way to easily give a name to a condition, and these two conditions are somewhat verbose, checking against four targets for each one.

However, @lqd and I have recently been doing some large scale measurement and analysis of popular crates. We have learned several relevant things.

• log is a very popular crate, the 7th most commonly used in our data set.
• Build scripts, even tiny ones, have a non-trivial effect on compile times of projects, because they (a) take a small amount of time themselves to build and then run, and (b) more importantly, they add dependencies to the compilation graph.
• Build scripts, even tiny ones, can be quite large on disk, because they contain debug info from std. Around 4MB is typical on my Linux machine.
• log's build script is number 28 in the list of compile times across our entire analysis, even though it's so tiny. (log itself is number 23.)

Full data is available here.

With all this in mind, it seems worth eliminating log's build.rs file. To avoid repeating the target conditions multiple times, it would make sense to restructure the conditional code into modules. I haven't tried this myself, but just from looking at the code it doesn't look too hard. The change to do this should include a comment explaining why a build script is worth avoiding 😄

This change will make little difference to the build times seen by the log developers, but would save a little compile time for everyone who develops code that depends on log. Across the entire Rust ecosystem, this will have a significant effect.