Binary release?

[damiendoligez]

Where can I find a binary installer of flexdll 0.36?

[alainfrisch]

I haven't created binary releases for flexdll 0.36 yet. See #32 for a discussion.

[alainfrisch]

Ok, I've uploaded my first attempt at binary releases on https://github.com/alainfrisch/flexdll/releases/tag/0.36 (both the .zip and the installer).

They have been built with the 32-bit mingw port of OCaml 4.06. This means that flexlink.exe should be Unicode aware and that it should run about anywhere (on 32-bit machines, and on machines without any MSVC redistributables).

The msvc support files (flexdll_msvc.obj and co) have been built with VS2015. My guess is that they would not work with older or newer versions of Visual Studio, but I might be wrong. @dra27?

[alainfrisch]

@damiendoligez Did you need to get the binary distrib for testing purposes, or to update README.win32.adoc?

[nojb]

My understanding is that objects built with VS 2015 will work with newer versions, but not older.

[damiendoligez]

I needed it for updating the CI machines, but I ended up recompiling flexdll myself, which is a good thing because the CI machines are on VS 2013 for the moment.

[dra27]

Just for "ease", I'd keep the binary release using VS < 2015

[alainfrisch]

Anyway, I screwed up the release, the msvc64 objects have been compiled with the 32-bit cl (I used MSVC_DETECT=0, shame on me), so I'll need to do it again.

What do you mean by "ease"? This will certainly be easier for users with VS < 2015, and one can guess that most OCaml users are in this case (because that's what previous binary releases of flexdll supported). But shouldn't we give an incentive to switch to newer versions (with the hope to be able to get rid of supporting older versions of VS at some point)?

I thought also on the following: one could consider VS < 2015 and VS >= 2015 as two different toolchains for flexdll, and ship *.obj files for both in the binary release.

[nojb]

In the short term, I think that shipping both versions would be best for "ease".

But longer term, wouldn't it make sense to compile the support code as part of the OCaml compilation process (using the same toolchain as the rest of the compilation process) and install the object files in the OCaml library directory, where flexlink could look for them ?

[dra27]

@alainfrisch wrote:

Anyway, I screwed up the release, the msvc64 objects have been compiled with the 32-bit cl (I used MSVC_DETECT=0, shame on me), so I'll need to do it again.

I did propose having a configure script 😉

By ease, I meant more "path of least surprise" - so VS2013 and earlier existing users have been used to it "just working" but existing VS2015/VS2017 users must already be used to having to at least running make support themselves. i.e. keep the binary release of 0.36 with the same warts as 0.35 and earlier.

We should indeed be incentivising upgrades to newer VS, but we can't always force it (especially in a binary-based world like Visual Studio) - however, this whole issue is a non-problem in Opam, so the worry here is going to be a thing for advanced users only soon (really, really, really......!)

However, 4.06.0 requires upgrading to flexdll 0.36, so I think we should be focusing on keeping the process of acquiring flexdll as similar as possible to the previous version.

My only problem with adding a new toolchain (given that it's to do with the use of UCRT, we could call it say msucrt and msucrt64) is that we would need somehow to expose that to OCaml's config/Makefile or else be probing cl for its version each time, both of which seem a little tedious.

@nojb wrote:

But longer term, wouldn't it make sense to compile the support code as part of the OCaml compilation process (using the same toolchain as the rest of the compilation process) and install the object files in the OCaml library directory, where flexlink could look for them ?

The code is of course already there to do this, it'd just mean actually shipping the flexdll directory. That said, I think Alain's solution of having flexlink able to compile the C objects automatically (and so have OCaml instruct it to install) is the more general purpose route, which feels better to me (as it still allows, say, Yaakov to package flexdll for Cygwin easily as a separate package).

[dra27]

See #43 for some alterations to the Makefile to prevent accidental use of MSVC_DETECT=0 when compiling a full release 😉

However, you'll then find that you can't build with VS2015 because we need to "upgrade" from my old findwinsdk script to the new shiny msvs-detect - in other words, we need to revisit #17.

[alainfrisch]

My typical setup has msvc installed in completely non-standard locations, so I really need to still be able to configure the PATH myself (say, pointing to the 32-bit toolchain; the 64-bit one can found relative to it). Does #17 still allow that?

[jakoblichtenberg]

I'd like to move my OCaml installation from VS2013 based to VS2015 based. In past I have downloaded binary version of FlexDLL. It looks like that will not work anymore?

[alainfrisch]

The binary distribution of FlexDLL now includes the source code for two C support files. You will indeed need to recompile them manually, using command lines found in the Makefile, if you want to use VS2015.

[jakoblichtenberg]

OK. Thank you. I think I got it to work using FlexDLL 0.37 and OCaml 4.05 using the provided instructions in the OCaml README.Win32 file (that looks to be improved a bit in OCaml 4.07 that I am slowly working towards). Thank you. The failure to find ocamlopt during first 'make flexdll' threw me off at first.