Make the build reproducible

[basvandijk]

numtraits' build script causes non-reproducible autocfg's files to be written to OUT_DIR:

$ cargo build
...
$ ls -la target/debug/build/num-traits-1caa1923b38178a5/out
total 24
drwxrwxr-x 2 bas bas 4096 May 14 10:20 .
drwxrwxr-x 3 bas bas 4096 May 14 10:15 ..
-rw-rw-r-- 1 bas bas  460 May 14 10:20 autocfg_02ed89fc39f41e87_0.ll
-rw-rw-r-- 1 bas bas 2445 May 14 10:20 autocfg_02ed89fc39f41e87_1.ll

Those hashes in the filenames and the contents of the files will be different for every build.

This causes issues in build systems like bazel with rules_rust that treat OUT_DIR as the package's output. Since the output is different for every build it means reverse dependencies of num-traits have to be rebuild every time num-traits changes.

We fix this by adapting the build script to let autocfg write its intermediate files to a temporary directory.

[cuviper]

It seems to me we'd be better off fixing this for everyone in autocfg itself, perhaps simply by removing those *.ll files after each probe? There's no need to keep those files around at all.

[basvandijk]

It seems to me we'd be better off fixing this for everyone in autocfg itself,

Makes sense!

perhaps simply by removing those *.ll files after each probe? There's no need to keep those files around at all.

Or what about letting AutoCfg::new() write to a temporary directory instead of to OUT_DIR?

[cuviper]

Or what about letting AutoCfg::new() write to a temporary directory instead of to OUT_DIR?

I'd rather not take any dependencies -- autocfg is as minimal and universal as it can be.

[cuviper]

See cuviper/autocfg#75

If you're able to test that in your build system, that would be great!

[basvandijk]

@cuviper thanks for merging your fix! I haven't gotten around testing it yet but I'll give it a shot next week.