[distribution] binaries: Provide latest windows builds

[slyshykO]

• [X ] Operating system: e.g. Linux, Mac OS X, Windows (with specific version)
  Any chance that we cat provide a binary for windows in releases?
  @xor-gate

[xor-gate]

Long time ago I tried to build with appveyor on windows with mingw toolchain. Its a pain in the ass to get right. I'm only running *NIX and macOS. The best would be automated building.

[slyshykO]

add the ability to build under Linux #802

[Nightwalker-87]

It seems to me that we should have improved support for windows. I know we have support currently, but this should also include travis build testing and improved documentation (see also #795) regarding the installation procedure. On top of that it would be desirable to find somebody who is willing to compile the whole toolset up and down regularly on a "real world" local machine to ensure everything is working well and to detect caveats.

[Nightwalker-87]

@slyshykO: Can we provide binaries for Windows now based on PR 805? Can you explain?

[slyshykO]

@slyshykO: Can we provide binaries for Windows now based on PR 805? Can you explain?

@Nightwalker-87 Did you mean #802? If so, I think yes. The project has the ability to be built for windows. And one of the options is to build in Travis.

[Nightwalker-87]

Eh - yes of course. As you seem quite familiar with this topic, can you add some instructions to /doc/compiling.md and /doc/release.md via a PR and link this ticket to it? We can then add this as a documentation-update to Release 1.6.1.

[Nightwalker-87]

Related to #738 and #795.

[Nightwalker-87]

@slyshykO: I have squashed your .cmake modules from #802 to one single config and integrated it as a separate make target called "Binary". Currently this is only for testing, but the trick will be to properly detect the downloaded libusb library. We cannot use FIND_PACKAGE_HANDLE_STANDARD_ARGS here as we do when on windows, as this fails on debian based systems (no surprise really). If we can find a way to get over this, the idea may end up in a convenient solution.

[slyshykO]

@Nightwalker-87 What problems with #802?
I've tested them under Debian. It passed our CI.

[Nightwalker-87]

I'd prefer a solution which integrates into our build configuration well, meaning Windows binaries should build automatically, if MinGW is detected on a Debian-based system. Also both modules consist of duplicated code which can also be simplified.

[slyshykO]

If you know how to do better please do it.
But why you deleted working solution before new solution appears?

As I know, toolchain files it is a common use case for cross-compiling with cmake.

[Nightwalker-87]

We are not dependent on this functionality while we are in the state of development. Note that a development branch does not claim to provide all features at all times, therefore we have a master branch. Binaries can be provided using windows anytime and your implementation is still present in the latest stable release, if one should really need it right now. When actively working on a topic, I personally don't fancy to have old implementations present while working on an improved or modified solution.

[Nightwalker-87]

Also it does not work on my system (even) when using the master branch when following instructions provided in the toolchain file:

$MYDIRPATH$/git/stlink/build$ cmake -DCMAKE_TOOLCHAIN_FILE=./cmake/linux-mingw64.cmake 
CMake Warning:
  No source or binary directory provided.  Both will be assumed to be the
  same as the current working directory, but note that this warning will
  become a fatal error in future CMake releases.

CMake Error: The source directory "$MYDIRPATH$/git/stlink/build" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.

A passing CI build does not imply that a feature is actually working, it only reveals that compilation succeeds without any errors. When building into the source directory the compilation runs but does not generate any binaries in /dist/windows nor anywhere else.

[slyshykO]

CMake Error: The source directory "$MYDIRPATH$/git/stlink/build" does not appear to contain CMakeLists.txt.

You run cmake in wrong directory. It is not toolchain file fault.

[Nightwalker-87]

No... I have also tried the project directory itself.

When building into the source directory the compilation runs but does not generate any binaries in /dist/windows nor anywhere else.

In general there is no documentation on it.

[Nightwalker-87]

I have spent some efforts to automate the binary generation on Debian with a shell script. A script seems necessary as otherwise the inclusion of a cross toolchain file would let the build iterate into itself in an endless loop. 😆
Binaries are now generated, but the packaging has to be implemented in such a way, that the archive unzips to the correct windows paths (for convenience). cpack currently uses the file tree of the generated build folder. This topic is covered by #738.

The new implementation can be found on the branch dist.

Full package generation can be achieved on debian-based systems with the commands:
make package && sh ./cmake/packaging/windows/generate_binaries.sh.
All generated packages are subsequently placed in the subdirectory /build/Release/dist.