Windows YARP binary installer missing things.i

[jgvictores]

Some time ago we decided it was safe to include files for generating bindings after having installed YARP binaries in Windows. In a recent installation of YARP on a Windows machine, VS compilation of Python wrappings broke because of a missing things.i (required at bindings/yarp.i#L1213).
I installed yarp_2.3.64_v12_x86_1.exe on an Ubuntu+Wine, and this things.i is effectively missing. This actually affects all bindings, and is most probably an issue of several installers.

Could things.i please be included in future Windows YARP binary installers (or merged within yarp.i)?

[traversaro]

I guess this will be fixed by #1372 .

[traversaro]

@jgvictores We are discussing about the ideal way to proceed on how to use bindings of YARP in Windows (see #1372 (comment)). If you have a bit of time, can you described your ideal workflow? Thanks!

[jgvictores]

Yes, of course!
I agree with it would be tricky to distribute the bindings binaries with the YARP installer, because they would need to target a specific version/binary of Python or Lua, as there are several binaries available for this languages, and there is no "obvious" one to target.
What @lornat75 and I spoke in a pre-github era (mailing list, somewhere lost in nabble archive) is that what would be reasonable is to be able to install downloaded YARP binaries, and then compile specific bindings (I'm a Python fan now, and back then was interested in Java for use through Matlab).
This workflow actually worked on Windows until yarp.i started depending on a new file called things.i which was not included in the binary installer (in fact, one could download the file manually and compile the bindings).
It would be great if that workflow could be recovered/maintained. :-)

[traversaro]

So the idea is that the ${INSTALL_PREFIX}/bindings directory will contain yarp.i + a CMakeLists.txt suitable to generate and compile the bindings, right?

[jgvictores]

Yes, precisely!

[jgvictores]

Hadn't noticed, this was essentially fixed on 2017-09-12 via f86aaaf, but Windows installers were not affected till recent v2.3.72 release on 2018-02-12. New issues have arised, but closing this one! :-)