[READY] Use upstream Doxygen archive - fixes Travis

[bstaletic]

The FTP server pointed to by the old URL doesn't exist any more. Instead, this PR uses the upstream Doxygen archive URL. Though I'm not sure how long will the archive stay there after they release a new version.

[YannickJadoul]

Any idea how we could fix the remaining error?

$PY_CMD -m sphinx -W -b html docs docs/.build
Running Sphinx v1.8.2
making output directory...
doxygen: error while loading shared libraries: libclang.so.6: cannot open shared object file: No such file or directory
doxygen: error while loading shared libraries: libclang.so.6: cannot open shared object file: No such file or directory
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 29 source files that are out of date
updating environment: 29 added, 0 changed, 0 removed
reading sources... [100%] upgrade                                               
Warning, treated as error:
/home/travis/build/pybind/pybind11/docs/reference.rst:17:doxygendefine: Cannot find file: /home/travis/build/pybind/pybind11/docs/.build/doxygenxml/index.xml
The command "$PY_CMD -m sphinx -W -b html docs docs/.build" exited with 2.

[YannickJadoul]

Any idea how we could fix the remaining error?

Actually, I just checked, and maybe updating to 1.8.15 might help? I'm reading now next to this download: "Compiled using Ubuntu 16.04 with kernel 4.4.0 and gcc 5.4.0 and statically linked again libclang."
Given that the download is also ~ 40 MB compared to ~ 20 MB for 1.8.14, I'd estimate there a chance that this wasn't the case before, causing the error above.

[bstaletic]

When I was submitting the PR, there was no 1.8.15. Let me try updating it.

[YannickJadoul]

I've tracked down the MSVC issue. This commit should fix it: YannickJadoul@1f23277

[bstaletic]

@YannickJadoul Thanks for that. Since it's just a using declaration, I think it's fine to let all compilers use what works for MSVC, since it will be compiled to the same assembly.

[wjakob]

This looks good, but can you split this into two separate PRs? (after all, these are two completely different issues)

[bstaletic]

I can split into two PR, but I thought it's better to fix CI in one go, than to have two PRs each fixing one of the CI providers.

[wjakob]

At least having two commits would be helpful (with one addressing documentation, and the other for the internal MSVC segfault)

[bstaletic]

Alright, I've split it into two commits.

[wjakob]

Ok, thanks!

[wjakob]

The CI tests fail after merging this PR: https://ci.appveyor.com/project/wjakob/pybind11/builds/21354272/job/xk1wx8hh7f1050p0

[YannickJadoul]

Huh, that's weird. @martinRenou's #1641 was rebased onto this master is is now succeeding. And the VS 2015 were green before; this PR was only needed to fix the VS 2017 update.
Could this be a fluke in this particular AppVeyor run?

[YannickJadoul]

Now a different test is failing: https://ci.appveyor.com/project/wjakob/pybind11/builds/21358020
And looking at the history, even different tests are failing there. So is there some kind of race condition triggered by this test_gil_scoped ?