@testrunner123, thanks! @vmuriart, @tiran, @brianlloyd, @tonyroberts and @rickardraysearch, please review this.

Codecov Report

Merging #510 into master will increase coverage by 0.24%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #510      +/-   ##
==========================================
+ Coverage   76.89%   77.14%   +0.24%     
==========================================
  Files          64       65       +1     
  Lines        5583     5617      +34     
  Branches      889      888       -1     
==========================================
+ Hits         4293     4333      +40     
+ Misses       1000      996       -4     
+ Partials      290      288       -2

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 19d854c...6b8504d. Read the comment docs.

We have some lookup code for Visual Studio paths in setup.py, could you incorporate this somehow here?

I agree with @filmor about locating cl.exe from default directories, if the build is not started from VS command-line prompt with pre-configured paths. Also we should probably still allow to fall back to clang, since it is much lighter dependency on Windows than MSVC. Even pycparser recommends Clang for Windows:

https://github.com/eliben/pycparser#31interaction-with-the-c-preprocessor

For Linux only gcc should be fine.

Finally right now this pull request is not testing this functionality with compilers due to interopXX.cs files already available. These files are only re-generated for new versions of Python or new combinations of Python flags.

I just tried to search the paths for mt.exe, msbuild.exe, and cl.exe used during build on Windows and the paths are totally unrelated to each other:

Here is proper way to locate cl.exe, or more precisely to setup environment variables to get cl.exe into path:

https://github.com/pypa/setuptools/blob/master/setuptools/msvc.py

This above module monkey-patches distutils (just import setuptools) to provide location of cl.exe for up-to-date compiler locations (distutils.py updates on much slower cycle):

https://github.com/python/cpython/blob/master/Lib/distutils/msvccompiler.py#L267

More details about this spaghetti code for msvc compilers in this article (see also comments):

https://blogs.msdn.microsoft.com/pythonengineering/2016/04/11/unable-to-find-vcvarsall-bat/

@denfromufa
I personally will not use clang on Win/Lin for several reasons:

1. clang based geninterop is potentially error prone
   Python for Windows (that I download from python.org) is compiled with MSVC. Python for my Ubuntu was compiled with Gcc. If I use another compiler with another runtime as the one used to build Python interpreter then I would risk to create bugs that should not be there. CPython Module Extension API is also platform dependent.
2. clang is unnecessary ballast for build system
   Clang introduces unnecessary effort when integrating pythonnet into complex project. In fact you need any "C Preprocessor" for geninterop, so why not to use the one that I already have (native to the platform). The purpose of my pull request was to provide information how this can be done.

I use CMake for build and it finds compiler paths automatically. I do not think that each package must do it on its own, because it is pretty complex problem.

Even pycparser recommends Clang for Windows:

There is no recommendation for Clang on linked page. Also there are no reports about problems with msvc/gcc on it. And I didn't meet any problems.

Finally right now this pull request is not testing this functionality with compilers due to interopXX.cs files already available. These files are only re-generated for new versions of Python or new combinations of Python flags.

But there is no test in existing codebase for clang-based geinterop either. I believe it is a different topic to create automatic test for geninterop script. I have tested it manually with Python 2.7/3.4 on Ubuntu 64-bit, Python 3.5 on Windows 32-/64-bit.

@filmor

We have some lookup code for Visual Studio paths in setup.py, could you incorporate this somehow here?

It looks like now clang on Windows is also used from PATH in geninterop.py. Or where is its path set ?

@testrunner123 please address merge conflicts

Since geninterop is an internal script that only needs to be triggered when we want to support a new Python version, I don't thinkt it makes sense to change it right now.