Lock down libc dependency version

[yupferris]

When working on one of my projects, the build more or less randomly failed today: https://travis-ci.org/emu-rs/emu-core-audio-driver/jobs/90010879

It fails when building coreaudio-rs (and just building coreaudio-rs on its own locally also fails for me on my mac with a clean checkout, though it worked just days ago), and it appears to be related to libc specifically. Moreover, it seems like different parts of coreaudio-rs pull in different versions of libc (coreaudio-rs appears to link against 0.1.10, whereas this library takes whatever the latest version is, which is currently 0.2.1+).

I'm not entirely sure actually if libc is the culprit for the failing build, since it looks like the libc versions haven't changed since the last successful builds, but it's probably smart to lock down the libc dependency in this crate in any case.

[yupferris]

I've just tested building coreaudio-rs locally against a local checkout of this lib with a libc = "0.1.10" dependency, and it appears to work fine now. Gonna make a PR so it can be reviewed.

[mitchmindtree]

Agh sorry about this, the libc version should definitely be locked down. Let's see if we can lock it at the new libc 0.2 version.

[yupferris]

aha, will try with that as well.

[mitchmindtree]

Oh! Only if it's no problem - thought 0.2 might be the more future proof option :)

[yupferris]

just tried with libc = "0.2.0", same errors as in the travis link. I'll also give it a shot with both this lib and coreaudio-rs pointing to 0.2.0 (or 0.2.1 for that matter) though, as I think the fact that they mismatch is the real culprit here.

[mitchmindtree]

Yeah I'm pretty sure they'll have to match

[yupferris]

Yep, just verified that it works locally with both pointing to 0.2.1. I'll go ahead and push the fix here, and also add a travis config and those fancy badges while I'm at it :)

Should there be a license for this package btw?

[yupferris]

I'll also update coreaudio-rs to use 0.2.1

[mitchmindtree]

Awesome :) Yeah a license might be a good idea, i'm not 100% certain what is compatible with core audio API however I'm guessing MIT should be ok as that's what PortAudio uses and it wraps parts of core audio also.

[yupferris]

Can you make me an owner so I can publish this, or publish it yourself?

[yupferris]

hmm actually this might not be the latest anyways; I ended up bumping the crate version twice and just now realized this repo is probably behind the actual 0.1.1 somewhere haha

[mitchmindtree]

I just added you as a cargo owner for coreaudio-sys (also added the RustAudio admin team in general).

[yupferris]

great, thanks :)

Any chance you can review the 0.1.1 thing? I just fixed everything from this repo, which it looks like was labelled 0.1.0, but that doesn't match crates.io, which is 0.1.1. Wanna be sure we're not missing any changes before publishing 0.1.2 now.

[yupferris]

ping :)

[mitchmindtree]

Sorry about the wait chap! Slipped my mind amongst all the other things that needed fixing :)

And yes you're right, I have an uncommitted change on my end for coreaudio-sys (though it's nothing significant). I'll do a PR with it so you can merge with it before doing your own PR and publishing :+1:

[mitchmindtree]

Oh my bad, you've already done the PR - I'll do the merge :+1:

[yupferris]

Thanks :D

[mitchmindtree]

Ahhh I just noticed you committed straight to the repo (that's probably why I missed it) - There's no problems in this case but I think it's clearest if we do PRs from our own forks for all changes, and avoid committing straight to the repos.

[yupferris]

Yep, sorry about that. This was actually a great example case for why I shouldn't've done that! I'll be more careful about that in the future.