Support older versions of cargo

[tcely]

The removal of build keys is a problem for older versions of cargo which is particularly important when bootstrapping cargo itself.

Please revert 5c317d5 as soon as you can.

[sfackler]

Continuing from the comments on that commit:

If you're bootstrapping from an old Cargo, you can downgrade the openssl-sys version, right? cargo update -p openssl-sys --precise 0.9.27.

[tcely]

I could pin openssl at 0.10.5 and openssl-sys at 0.9.27 and never get updates, but that's not a great solution either.

[sfackler]

I'm confused - if you're bootstrapping, you're going to be building a cargo linked against openssl-sys 0.9.27 that exists only to build a new cargo, right?

What are you bootstrapping onto anyways? It seems like you should be able to take a modern cargo and cross compile to whatever you're using, right?

[tcely]

The static cargo I have is 0.17.0 and I'm trying to build cargo with that.

The problem I hit is that without build keys I can't get a newer cargo version to build.
I tried the pinning of the older versions and discovered that the older build.rs won't accept libressl 2.7, so that's not going to work. I'm back to patching your Cargo.toml files after using cargo fetch again.

[sfackler]

Why is 0.17 the only version of cargo you can possibly use? All of these problems seem totally solvable.

[tcely]

Static builds of cargo have been broken since 0.17.0, see rust-lang/cargo#5266.

These problems are completely solvable, but your choice to drop the build keys just adds hoops that I don't see any reason for.

[sfackler]

Why can't you bootstrap off of a cargo that links to glibc?

I am not really on board with maintaining support for ancient versions of cargo forever because some build that someone uses stopped building at 0.17.

[tcely]

This OS doesn't use glibc. I'm curious why you are insisting on removing these keys. Does it give some advantage?

Hiding the build script behind "magic" handled in cargo itself seems to just make it harder to figure out what's going on when reviewing the Cargo.toml file.

[sfackler]

This OS doesn't use glibc.

Bootstrap a MUSL-linked cargo from a glibc-linked cargo.

I'm curious why you are insisting on removing these keys. Does it give some advantage?

The ability to use features from Rust releases after 1.17 is important. I could revert this change but this kind of thing would just happen again in the future with something else.

Hiding the build script behind "magic" handled in cargo itself seems to just make it harder to figure out what's going on when reviewing the Cargo.toml file.

It is no more magic than an implied lib.rs crate root.