Windows build environment for dynamic linking of ZeroMQ

[hansieodendaal]

This change to assist Widows users to build rust-zmq when using ZeroMQ dynamic link libraries. Changes incorporated:

• some Windows specific build instructions;
• adding a function to zmq-sys/build.rs to verify the Windows build environment and
• adding 2x helper batch files to assist users in setting up their Windows environment after compilation of ZeroMQ.

[hansieodendaal]

This cargo test --verbose --features unstable-testing seems broken for rustc 1.35.0-nightly (4c27fb19b 2019-03-25) but succeeds for rustc 1.35.0-nightly (e68bf8ae1 2019-03-11)

failing-rustc-1.35.0-nightly-2019-03-25-Ubuntu.txt failing-rustc-1.35.0-nightly-2019-03-25-Windows10.txt success-rustc-1.35.0-nightly-2019-03-25-Windows10.txt

[rotty]

Sorry, I haven't had time to give your build system changes a proper review, but here are some initial thoughts:

• The Windows build instructions are certainly very welcome, especially as I don't privately run Windows, so I have no idea of any peculiarities there.
• There is a somewhat related issue, #257, and PR #241. I hope that eventually we will end up with a vendored feature flag that makes static linking against libzmq much easier, using the proposed libzmq-src crate. I'm not yet sure if this approach is applicable for dynamic linking, though, which is important due to the LGPL license of libzmq.
• The .bat scripts you supplied are, to be honest, hard to look at, to the point where I don't want to review them. They seem overly long for what they are supposed to accomplish (if I understand their purpose correctly). They also seem extremely repetitive. I'm sure this is due to cmd just being a horrible language. Since they seem to require powershell anyway, perhaps doing this in powershell would improve the legibility to the point where they become reviewable to me?

[hansieodendaal]

Hi Andreas,

Thank you for the response:

• I have looked at the PRs you mentioned, the one I am very familiar with.
• You are right, coding in cmd is not pleasant, and not easy to read. Making them robust seems to make them repetitive. The batch files could be completely removed if we put some more instructions in the README.md file if you prefer that, however, this would defeat the purpose.
• The only way to really review the Windows scripts are to run them in a Windows environment. These batch files are only helper functions to prepare a user's environment and cannot break rust-zmq.
• Very few Windows users are familiar with PowerShell, including me. I only use it when I really have to, for example to reliably clear registry entries from within the cmd environment or to change the case of command line parameters.
• The length of the path environment variable in Windows is limited, and depending on what a user have installed it is not practical for everyone, including me, to permanently add LIBZMQ_BIN_DIR to their path, but rather to source it when needed.
• PowerShell and cmd do not play well together when setting session paths. Each can inherit the environment from the other, but one cannot call a PowerShell script from cmd to change the session path for the cmd environment and vice versa.
• The cmd file win_set_environment_vars.bat works equally well when called from either cmd or PowerShell, so I propose we leave that one as is. It is also only run once to add the LIBZMQ* environment variables persistently to the registry.
• I can add a win_source_dll_path.ps1 script for users who want to work straight from a PowerShell environment without instantiating it from the cmd environment.

Your thoughts?

[rotty]

You are right, coding in cmd is not pleasant, and not easy to read. Making them robust seems to make them repetitive. The batch files could be completely removed if we put some more instructions in the README.md file if you prefer that, however, this would defeat the purpose.

Having more extensive instructions would be great! I'd feel more comfortable with that than with scripts I cannot be bothered to understand ;-). Maybe it makes sense to wait on how PR #262 works out, befor adding more extensive Windows build instructions, as that PR will have implications on the build instructions for all platforms.

The only way to really review the Windows scripts are to run them in a Windows environment. These batch files are only helper functions to prepare a user's environment and cannot break rust-zmq.

I'm aware of that, but the thing I'm not comfortable with is that users in the future might be running into issues with these scripts, reporting them on github, and no-one can help them out.

[hansieodendaal]

Hi Andreas,

I updated the Windows build instructions for dynamic linking and removed the batch files from the system (but left a GitHub gist link in case anyone want to use them).

I checked out PR #262; my proposed changes can easily be integrated and is not conflicting in any way.

Regards

[rotty]

Oh, and additionally, please squash (and if, applicable, rebase) your changes, giving the resulting squashed commit a fitting commit message. I prefer to have a simple git history, instead of preserving the the evolution of each PR for posterity in the git repository, as you would get when adding fixup commits to a PR. A PR should only contain multiple commits if they are separate logical units, which can be understood on their own.

I really need to write up that CONTRIBUTIONS.md document.

[hansieodendaal]

Hi Andreas,

All suggestions implemented. Just need to do the squash & rebase bit. ... Done!

[rotty]

I've now squash-merged your release/v0.8 branch, modulo some whitespace adjustments, and will merge release/v0.8 into master soonish. Thanks!