-Lblahblah doesn't work, and emits an "unknown flag" warn
windows_find_package is a no-op out of the box, we offer an option to make it work, but that's off by default, the construct here is to be expected, don't think it needs a comment?
including…
- pacman still does a whole bunch of stuff every time I build , once installed i want to see no more pacman shennenigans
Checking for msys2 base
Refreshing pacman
:: Synchronizing…Little weirded out by some of the actual code changes fixing the shadowed variables, we're doing this to get close to the GCC/Clang set of warnings, and we end up fixing a bunch of stuff they…
LGTM, in the commit message I would start by providing the text description of the warn, so people do not have to figure it out from context what this is about.
Is the usd change still needed? didn't 4cc94679ddb0d538493ead9e360ca38da0d58b3c fix that?
The installer makes shortcuts to blender-launcher.exe ever since we introduced it, as do the steam and the ms store installers. Pinning blender on the taskbar is getting fixed, but that code isn't…
missing endif()
CMake Error at cmake/setup_msys2.cmake:97 (if):
Flow control statements are not properly nested.
Call Stack (most recent call first):
CMakeLists.txt:43 (include)
…
Testing locally i'm only seeing an /out directory and and out/build folder, can you validate where your /build folder is coming from?
If it's not critical, there is no need to update them no?
You can probably nick the nasm install from the old mingw code.
If its a fixed URI, we could just grab it in setup_msys2.cmake and place it in a convenient location (ie somewhere the msys2 tree) for all deps to use if they need it.
I'm not sure if it's a good practice to put the build files inside the repository whose files are affected by CMake.
VS is just bad in this regard, out of tree builds just aren't a concept…