alainfrisch
commented
9 years ago Thanks!
I haven't been able to test your script since we deploy the toolchain simply by copying some directories on our dev machines (no registry). I've only adapted the Makefile to call the script through bash explicitly to avoid permission issue (setting the execution flag on the script).
Detection code for the Microsoft C compilers assumes (with comment!) that the 32-bit version is installed.
Rather than hacking that code to fallback and try to detect the 64-bit version, this patch attempts to query the actually installation of the Windows SDK and tries to locate its SetEnv script. It then calls SetEnv in a way which allows it to extract the PATH, LIB and INCLUDE changes that it would make (this is relatively easy because SetEnv only updates the start of the environment variables).
These are then used to allow FlexDLL's Makefile to set PATH in the same way as it sets LIB and INCLUDE before calling cl, but it removes some of the "guesswork". The old detection code is left in place for installations using Visual Studio rather than the WinSDK (I'm afraid I'm a bit too lazy to set a snapshot machine up just to test Visual Studio 2008)
The patch allows flexlink.exe to be built very liberally - i.e. in an environment where ocamlopt wouldn't normally work because of a lack of ml.exe/ml64.exe.
I've also "fixed" version.rc to include rather than the older afxres.h as the standard Windows SDK (and I believe express versions of Visual Studio?) don't include MFC support files.
Tested in various configurations - the mingw builds of flexlink.exe and their support files still work and, on a machine with the MSVC build of OCaml in PATH, but not ml.exe, it is possible to run: make CHAINS="msvc msvc64" support flexlink.exe and it correctly determines which C compiler to select based on OCaml's Makefile.config The test suite also seems to be working.