Make AcceptFirstCompile public

[tuguzT]

This is needed for Rust-GPU/cargo-gpu#112 to add watch() method for shader crate builder of cargo-gpu-build crate.

[Firestar99]

I kinda hate how convoluted the current watch API has gotten. If you want to, feel free to completely refactor it into whatever suits you best.

[tuguzT]

The best API I could think of is the channel-like one...
But I guess this could be done in a separate PR, or is it better to do now?

Also I could not find any tests for watch feature... Maybe make one?

[Firestar99]

Whatever you feel like is easier. I just want to encourage you to make a new API if you have a better idea, rather than trying to keep supporting the existing one (like I did in the past).

Not sure how viable it is, but do we even have to spawn a new thread? Couldn't we just eat the current thread and have the argument be a closure that handles the result of a compile? Then the application can spawn a thread and move the data through a pipe, if it wants to. But it doesn't have to.

[tuguzT]

Whatever you feel like is easier. I just want to encourage you to make a new API if you have a better idea, rather than trying to keep supporting the existing one (like I did in the past).

I agree that rewriting this API could be beneficial. But I just wanted to patch it to finish cargo-gpu's library / binary split first, and then I could rewrite watch API. It's more than 2 weeks by now...

Not sure how viable it is, but do we even have to spawn a new thread? Couldn't we just eat the current thread and have the argument be a closure that handles the result of a compile?

As I see by notify documentation, this is already possible.
My idea now is to expose refactored Watcher, which could just return CompileResult on recv(), then we don't need to accept any callbacks, differentiate first compile result from others, etc.

Then the application can spawn a thread and move the data through a pipe, if it wants to. But it doesn't have to.

Yes, I think that could be easily done on cargo-gpu binary side. Or it could just eat the current thread.

[tuguzT]

Closing this for now in favor of #422