mixxx
mixxx copied to clipboard
mixxxdj
clarify Windows build instructions
Adding note about potential issue when executing the windows_buildenv.bat from Powershell
Can you also sign https://docs.google.com/a/mixxx.org/spreadsheet/viewform?formkey=dEpYN2NkVEFnWWQzbkFfM0ZYYUZ5X2c6MQ
In this case this is not really required, but we are looking forward to your future contributions, where it will.
The README already states which command prompt to use:
If we want to mention that powershell is not supported, we should add it inside the parentheses I think.
E. G.:
(on Windows, use "x64 Native Tools Command Prompt for VS 2019", Powershell is not supported)
A CMake build in Visual Studio doesn't use a .sln file at all. This sentence make no sense to me.
It's indeed difficult to find this shell "x64 Native Tools Command Prompt for VS 2019", but the text is correct. Maybe it should be added, where this special shell can be found (Start-Menu -> Visual Studio 2019 -> Visual Studio Tools -> VC -> x64 Native Tools Command Prompt for VS 2019 BTW: This special shell is only needed for command line builds. To only execute the windows_buildenv.bat, you can use any cmd.exe shell. Usually a double click on the file windows_buildenv.bat does the job without opening any shell.
A CMake build in Visual Studio doesn't use a .sln file at all. This sentence make no sense to me.
Neither does the command line build if you use the Ninja Generator (which should be chosen automatically because the bach script sets the appropriate env vars).
It's indeed difficult to find this shell "x64 Native Tools Command Prompt for VS 2019"
Are people actually using application launcher ("start menu" on windows) without making use of the search function? ;-)
Are people actually using application launcher ("start menu" on windows) without making use of the search function? ;-)
If they know, that they've to look in the Start Menu for "x64 Native Tools Command Prompt for VS 2019" - and not in the Tools menu of VS2019 itself, where the developer command prompts are located.
I'll be honest, the first time I installed I just double clicked the batch file. That gave me the failed to download error in my first post.
On Mon, Sep 20, 2021, 12:34 PM JoergAtGithub @.***> wrote:
Are people actually using application launcher ("start menu" on windows) without making use of the search function? ;-)
If they know, that they've to look in the Start Menu for "x64 Native Tools Command Prompt for VS 2019" - and not in the Tools menu of VS2019 itself, where the developer command prompts are located.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mixxxdj/mixxx/pull/4311#issuecomment-923089073, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBGPPLHRLQSBFPVW4GL6ALUC5PABANCNFSM5EKYLG6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Double clicking on the .bat file works for me, but on my system plain cmd.exe is the default shell, and not powershell. On Unix systems, you have the Shebang line at the beginning of a script, which selects the interpreter for a script. I don't know something similar for Windows.
Thank you for signing the contributor environment. I think this PR is the evidence that the current build instructions can make use of an improvement.
First, open a terminal ...
In the first paragraph is not explicit enough IMHO, because it covers all targets.
Do you have interest to rephrase this and describe the windows case more explicit? I have something in mind like an extra sentences: On Window, use the "Developer Command Prompt" (Start Menu -> Visual Studio XXXX -> Visual Studio Tools) ..." And than add the extra info about the shortcut "Developer PowerShell for VS XXXX" Does it work, or does it lead to the described issues as well?
This PR is marked as stale because it has been open 90 days with no activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Start Menu:
About automatic shell selection: .cmd and .bat files are executed by cmd.exe, because they are shells commands, not powerbuild commands. What changed on Windows recently is that the default console is now Powershell instead of cmd.
In that case, two quick solutions can be mentioned:
- type cmd on start menu and run the command prompt application.
- open powershell and when it is opened, type cmd and enter.
Both of these will give a cmd-based command prompt to windows users.
Note that recently some changes where made to the windows_buildenv.cmd on main because it was not safe for folders with spaces in the name.
Also note that the windows_buildenv.cmd on the 2.3 branch has a small problem on the generation of the CMakeSettings.json. CMAKE_PREFIX_PATH is generated erroneusly and then Visual Studio considers the file damaged and ignores it. The one in the 2.4 branch has these things fixed, but points to the 2.4 buildenv.
On windows, you cannot build applications from the default shell. You need to open some kind of "Developer" shell. We explicitly mention what command prompt you need to use, so I think are all good here. Let's close this PR and move on.
Not sure if this PR also fixes: https://github.com/mixxxdj/mixxx/issues/10920
@rbax do you have interest to continue here?
@JoergAtGithub I am unsure if double clicking of the windows_buildenv.bat still works.
We have recently introduced a new environment variable MIXXX_VCPKG_ROOT for finding the vcpkg toolchain file. Can you confirm that it is available at the Developer Command Prompt?
@JosepMaJAZ would you mind to port the mentioned 2.4 fixed to 2.3? This seems to take away some if the headaches from first time contributors on Windows.
Regarding the CMAKE_PREFIX_PATH: for my understanding we must not touch it. It should be set properly by the vcpkg toolchain file. Can one of you confirm that?
Thank you.
Ok, here's the PR with the changes to the windows_buildenv for 2.3. Removed CMAKE_PREFIX_PATH and made use of MIXXX_VCPKG_ROOT (which points to BUILDENV_PATH, when generating the json so nothing really changes).
https://github.com/mixxxdj/mixxx/pull/10949
Build test with both, Visual studio + CMakeSettings, and also from command prompt.
@JoergAtGithub I am unsure if double clicking of the
windows_buildenv.batstill works. We have recently introduced a new environment variable MIXXX_VCPKG_ROOT for finding the vcpkg toolchain file. Can you confirm that it is available at the Developer Command Prompt?
I can confirm, that double click on windows_buildenv.bat still works on Windows 11.
But how should I check this variable?
After restart, open cmd.exe and echo %MIXXX_VCPKG_ROOT%
Double click the bat file, than open a new cmd.exe and echo %MIXXX_VCPKG_ROOT% again.
After restart, open cmd.exe and
echo %MIXXX_VCPKG_ROOT%Double click the bat file, than open a new cmd.exe andecho %MIXXX_VCPKG_ROOT%again.
This variable is not set! And I don't think an environment variable can work here at all. Just imagine two parallel Mixxx directories and just one global variable. It might point to the others buildenv.
That was my understanding before. That means double clicking will require to call CMake with either -DMIXXX_VCPKG_ROOT=... or like documented in the vcpkg manuals with -DCMAKE_TOOLCHAIN_FILE=...
Since this seems to be a common error, I think it is probably better to change our doc to use the cmake arguments instead of the environment variable. This is more reliable especially if you switch between branches.
What do you think?
The variables set on the windows_buildenv.cmd are just kept for the life of the console window opened. They are not intended as system/user global variables.
So, if one calls cmake on the console window after windows_buildenv.cmd, that will have the MIXXX_VCPKG_ROOT. With Visual Studio, the CMakeSettings use the cmaketoolchain file.
On a side note, the CMakeSettings is generated always, so it is a bit problematic to run it everytime to setup the environment, because it creates a new CMakeSettings.
Not sure what's the best way to improve this small part (As anyway, I consider not necessary to build from commandline on windows)
On the long term I suggest to switch from CMakeSettings to CMake-Presets: https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html CMake-Presets can replace CMakeSettings in the IDE case, but can be used, by CommandLine CMake build too.
On a side note, the CMakeSettings is generated always, so it is a bit problematic to run it everytime to setup the environment, because it creates a new CMakeSettings.
Ok, that confirms for me, that we should change the instruction to ad the toolchain file on the initial CMake call. it is not possible to change the toolchain file later anyway.