Automatically download raylib during raylib-sys's build

[tangmi]

Hi there! I'm very happy that I found your Rust wrappers for raylib! Please treat this PR just as a proposal. If the idea is good, it can be cleaned up.

I've implemented a build.rs script for the raylib-sys package that downloads the correct raylib library for one's current platform/architecture/environment (or fails if there's no existing pre-built download and raylib doesn't already exist in the library search path).

The main idea here is to reduce the barrier to entry to making a 3d game in Rust to "just add raylib = "..." to your Cargo.toml (on any platform) and everything will set itself up for you"

Some things that can definitely be improved:

• The archive extraction code assumes .tar.gz implies "unix" and .zip implies "windows". This is currently true for the current release, but doesn't have to be
• Depending on how complex it is to build raylib, we could build raylib for platforms that don't have an "official" release
• It might be possible to generate the ffi_*.rs bindings at build time since these changes make the raylib.h header download locally.

Edit: I've only tested this on windows, so there's probably additional work to ensure it works on macos and linux...

[deltaphc]

Thank you @tangmi for your contribution!

This looks pretty nice from what I can see. One potential issue I can foresee is when curl is not available on a Windows system (which is fairly likely). curl-sys does automatically build it if it doesn't exist on the system, but this assumes that the user has a C compiler installed and has it on the PATH. I am unsure if we want to assume this on Windows.

Another way to download a file on Windows is to go through PowerShell, which comes preinstalled since Windows 7 SP1 according to MS. This is, in fact, the way that the sdl2 binding does it. It doesn't assume that curl is installed, and it doesn't require a C compiler. We could perhaps use this as inspiration.

As for generating the bindings, this is certainly possible since bindgen can be used as a Rust API. This was suggested in another PR too. I think I would want this behind a feature flag in raylib-sys, not by default. But it's definitely something I would consider adding.

For building raylib from source, I would also welcome such a feature, as long as it, too, is behind a feature flag, for the same reason above in not assuming a C compiler.

[gshaw]

FWIW this branch worked brilliantly out of the box on Mac OS. Received a single warning during cargo build for the example app and cargo run showed the test app working.

% cargo build
    Updating crates.io index
...
   Compiling raylib-examples v0.10.0 (/Users/gshaw/Projects/raylib-rs/examples)
warning: unused import: `raylib::consts::*`
 --> examples/hello/main.rs:3:5
  |
3 | use raylib::consts::*;
  |     ^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unused_imports)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 1m 22s

Warning is easily fixed by commenting out the use raylib::consts::*; in examples/hello/main.rs.

[tangmi]

@deltaphc I'm trying to wrap my head around a nice way to deliver a good user experience... It'd be awesome if we could pull down a pre-build package (if on a supported platform) using some method available on each platform. If we could somehow check if there is a C compiler available (or maybe just have a documented feature flag), we could pull down the source and compile it on unsupported (i.e. no official prebuild release) platforms (I have another branch prototyping what this could look like).

Good find on the sdl2 bindings... I'll take a look at it next time I have some free time.

An aside on feature flags: raylib's architecture shows there are 7 core modules and 6 "extra" modules... I'm wondering if each of these modules would be good candidates to be put behind feature flags. Then, for instance, someone could pull down your package to use just the rlgl module.

Edit: I just realized that to build Rust on Windows, one either needs the VC++ Build Tools for the -msvc toolchain or use the -gnu toolchain (for their respective linkers?)... I'm unsure if this implies that a C compiler will always be available when building Rust packages...?

[Jengamon]

It does imply that, because that is, in fact, what the compiler uses to build code for Windows afaik.

[deltaphc]

You can probably assume that the msvc toolchain users have the VC++ build tools. However, the gnu toolchain does not require the user to install additional software; it includes a linker by default.

[tangmi]

Do you think it's reasonable to have the build step attempt the following (in order):

1. Detect and use a "system" raylib in rust's "lib" path, if available (using pkg-config, although looking at the source I'm worried this doesn't do much on Windows)
2. Attempt to download a prepackaged raylib if there exists an official release
3. Download an compile the source from an official release

Option number 2 might just add complexity to the build script (and not be necessary) as both 2 and 3 require a compiler in path and 3 works on "every" platform.

I don't think cc-rs has great error reporting (when a compiler is not in the PATH), but maybe a note in the installation instructions for raylib-rs that mentions either downloading an official release or ensuring a compiler and linker are available would be a pretty good user experience.

[Dacode45]

With 0.11 this is no longer necessary