Workarounds in build.rs for Windows compilation

[visceralfield]

• Usage of where on windows rather than which
• Slicing of Extended-Length Paths using regex on windows as a workaround to std::process::Command.current_dir not accepting them

[vitiral]

bors try

[visceralfield]

PR updated with code nice-ification

[bors[bot]]

try

Timed out

[vitiral]

never mind, it looks like travis windows nearly passed -- a couple of "serve" tests failed, which I'm not terribly concerned with -- especially if there is a windows user capable of PR's.

Would you mind taking a look at the failures and seeing if you can replicate+fix -- or at least see if they might be related to this PR? I wouldn't be surprised if they aren't related.

[visceralfield]

Alright, cleaned things up a little more. I've ran the failed Travis test cases on my local machine and was able to handle them without issue - I can take a deeper look and maybe uncover a little more this evening.

[visceralfield]

Update on the extended length paths issue. I ran the following code expecting passes to pass and fails to fail, but they both passed.

#[cfg(test)]
mod tests {

    use std::process::Command;

    #[test]
    fn passes() {

        let status = Command::new("where")
            .arg("cmd")
            .current_dir("C:\\Users")
            .status()
            .unwrap();

        println!("status: {}", status);
    }

    #[test]
    fn fails() {

        let status = Command::new("where")
            .arg("cmd")
            .current_dir("\\\\?\\C:\\Users")
            .status()
            .unwrap();

        println!("status: {}", status);
    }
}

So I need to go back and do more digging. It is possible that my workaround regex stuff isn't needed, and there is a simpler solution here. I will look into it this evening.

[vitiral]

Thanks for all of this.

I strongly support getting this running on windows, but just a heads up that I'm doing a rewrite in python for easier inclusion in build systems (and cross-platform support).

See #271