Given, particularly, the problem raised in #738, it seems there is probably only one correct way to install the current binary for Windows (v1.3.0).
However, as far as I can see, there are no instructions or guidelines on how to do that.
Please explain the steps required, and document them somewhere they will be seen, when trying to install it.
At the moment, it just says this:
**Installation
Windows users can download v1.3.0 from the releases page.**
but the binary contains no further information on what to do to install it, and neither does the downloads page.
It has been a very long time when I build the windows release, there are some people on the stm32duino forum which have newer build http://stm32duino.com/viewtopic.php?t=2515
Even this build is old 2017 馃槈
Yes, you could get your hands dirty and build one yourself https://github.com/texane/stlink/blob/master/doc/compiling.md#windows-mingw64 :=D
Thanks. I'll look into that :)
Any idea how to get past this error?
"CMAKE_MAKE_PROGRAM is not set"
I have followed the Windows installation instructions (I have some notes to add to that), and I can run cmake from the command line, but I haven't yet got any further than this:
C:\Users\andy\stlink\scripts>mingw64-build.bat
CMake Error: CMake was unable to find a build program corresponding to "MinGW Ma
kefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a differe
nt build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Ma
kefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a differe
nt build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
'mingw32-make' is not recognized as an internal or external command,
operable program or batch file.
'mingw32-make' is not recognized as an internal or external command,
operable program or batch file.
'mingw32-make' is not recognized as an internal or external command,
operable program or batch file.
@Andy2No , Do you have installed mingw64? If so, you should add it to the PATH.
I had installed mingw-w64, and chose the option to add shortcuts to the Start menu.
As is often the case in Windows 7, I then couldn't find it in the Start menu. Cmake was still highlighted, but that wasn't.
It seems they expect us to use a shortcut there, to launch a terminal with the environment already configured. It was in
Start Menu -> Programs -> MinGW-W64 project -> i686-8.1.0-posix-dwarf-rt_v6-rev0
and the shortcut is called "Run terminal"
That starts at the root of C, so a CD is needed to get to the working directory:
C:>cd C:\Users\andy\stlink\scripts
C:\Users\andy\stlink\scripts>mingw64-build.bat
I now have st-info.exe and st-flash.exe, both in the scripts folder, where I ran the build script... I wasn't really expecting them to be there, so maybe that should be added to the installation instructions.... maybe I've just missed that part.
Other suggested changes - I had a bit of trouble finding what to download for MinGW-W64. The link given in the installation instructions lead to me downloading the source. I found the .exe here:
http://mingw-w64.org/doku.php/download
(or Downloads, on http://mingw-w64.org/doku.php)
I think giving that link instead, would make the instructions clearer.
Also, I haven't used git clone a lot, so I had to look that up. A lot of people won't have used it at all, but it seems to be the best way to get sources from a git repository (especially if there are dependencies on other repositories), so a little more information would be useful there.
This worked (from my User folder, in a command prompt):
git clone https://github.com/texane/stlink
but someone using git from the command line for the first time would also need to do:
git init
If you feel like linking to a reference, I found it at:
https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository
2.1 Git Basics - Getting a Git Repository
(if not used before, read the part about git init)
For future reference, I've installed the current version of Cmake, with cmake-3.17.0-rc1-win64-x64.msi, and the current version of MinGW-W64, which is 8.1.0, using mingw-w64-install.exe
... which installed the MinGW-W64 binaries here:
C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0
I've attached the zipped package that was created, and the contents of the terminal window, mostly containing the compiler output.... subject to testing, when I get back up to speed on what I was intending to use it for, originally.
I think @slyshykO was referring to the $PATH system variable within the Windows system settings, not to the directory path / install path.
I think @slyshykO was referring to the $PATH system variable within the Windows system settings, not to the directory path / install path.
Yes, I assumed that was what he meant. There's also a path in the mingw64-build.bat file, and I missed that part of the instructions, but neither seems to matter, if you use the terminal shortcut provided with MinGW-W64 8.1.0 - I used the mingw64-build.bat file as supplied, without edits.
Windows does a slightly mysterious thing with the environment, so you don't necessarily need to alter it in system settings. A batch file like the one they provided (via the shortcut) is able to achieve the same thing, temporarily, by setting environment variables first. That only affects that particular terminal window, and doesn't persist after you close it, as I understand it...
Having said that, my path now has a few different entries for cmake and mingw-w64, which I may want to remove. Too many chefs, I guess.
The batch file they provide, via "Run terminal" does this:
echo off
set PATH=C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin;%PATH%
rem echo %PATH%
rem cd "C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin"
cd "C:\"
"C:\Windows\system32\cmd.exe"
Maybe I overlooked it in this thread but building st-link suite using MSVC toolchain for Windows 10 (x86-64) is suprisingly easy and straightforward.
msbuild and cmake)msbuild in default installation presumably should be in C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin directorymkdir build; cd build; cmake ..; msbuild <SLN_FILE>.sln /property:Configuration=ReleaseDone.
There's a st-utils.zip ZIP file containing all built executables.
Like most things, it's easy when you know how, Glaeqen.
I've detailed my process with decoding the instructions. Maybe that will help someone else, who is similarly confused by them.
Like most things, it's easy when you know how, Glaeqen.
Sorry, I did not mean to brag or to offend anyone. By _suprisingly easy and straightforward_ I was mostly referring to how flawlessly whole process went through - in contrary to my expectations. In my experience using msbuild is rather painful (I have more linux background) and this was a pleasant surprise.
I'm annoyed as well as others that there are no ready to use executables. Especially, when toolchain supports platform just fine.
No offence taken :)
I'm pleased to see this thread has still been left open. There's a tendency on github to close threads, which effectively hides them away from most people who might have wanted the same information.
@Andy2No: This ticket will be closed as soon as the related documentation has seen improvements that address this issue. This is currently planned for the upcoming release. If there are any further specific suggestions, please feel free to submit a commit.
@Glaeqen: I like your suggestion/proposal to use MSVS. To me this sounds like a suitable replacement for the (as of today) somehow outdated MinGW-Tools.
@bmarvo: What's your opinion on this?
@Glaeqen: Could you please open a PR to add the necessary support to build on MSVS?
@Andy2No: I have updated the README (23c071edea45f6e8852fef52d884a680973d6d8f), which is not the final state though, I know, but at least represents the current situation. Additionally our compiling instructions have been rewritten (27aa88821197d3ffe82baff4e971c3488ec39899).
Windows binaries are now built into a separate build folder during installation, but that routine still wants some clean-up. I'm working on it...
@Nightwalker-87 I'm sorry I left you with this issue for such a long time. I created PR #942 as you wished. I fought yesterday with develop branch, it appears you fixed it overnight. Nice job, CMake scripts now look nice and clean :)
@Glaeqen: Thx for your help; will look at it as soon as I find time. Still working on CMake packaging and will need some more time for that. Right now a working development branch has the highest priority. :sweat:
Most helpful comment
@Andy2No: I have updated the README (23c071edea45f6e8852fef52d884a680973d6d8f), which is not the final state though, I know, but at least represents the current situation. Additionally our compiling instructions have been rewritten (27aa88821197d3ffe82baff4e971c3488ec39899).
Windows binaries are now built into a separate build folder during installation, but that routine still wants some clean-up. I'm working on it...