2. Windows build - Use build script and full path#77
Conversation
2d5e3d4 to
0b99617
Compare
|
Update: Converted batch file to powershell script. Alright, after combining my changes from PRs 79, 77, and 78 all into one branch in my own copy of the repo, I ran into several issues where a Windows batch file just doesn't work well. I have added a commit converting the batch file into a powershell script instead. Anyone should be able to run |
0b99617 to
82bf596
Compare
move build steps out of the `.csproj` file and into a separate `.bat` file. this should make it easier to read and edit. you can use newlines no behaviour changes
expand path for `Dependencies.zip` with `~f` batch syntax ensures that powershell can always find the file
* improve quoting and handle input vars * make sure cd and directory expansion happens correctly
82bf596 to
832958b
Compare
bat file has many problems being stable and consistent, and handliing paths and input. powershell should be more reliable
use constants to remove repeated strings
832958b to
b534e61
Compare
* Wrap the entire script in 'try { .. } catch {}' brackets. This allows us to capture anything that went wrong and report it for both tests and visual studio
* Format a nice error message, and write that to stdout.
If we format it in a specific way, Visual Studio will display it nicely right inside the IDE, in the Error List window.
The user can click on that line to jump to the script.
* Use specific exception types when throwing exceptions, to better declare what is happening * Add input validation to check for empty args. This should never happen, but we might as well be robust to it. * Add checks for folders that don't exist * Extract some strings to constants * Add troubleshooting info on how to fix problems
Apparently pester has no way to easily get the name of the current running test. This has been an open issue since at least June 2020 - pester/Pester#1611 you can hack around it by setting an environment variable, but that makes the code pretty ugly. at least do this for now.
e2e6b0b to
17be5f6
Compare
* GB: Link cable support with two local consoles * GB: Fix crash when color blending is enabled * GB: Fix formatting * GB: Link UI fixes, control fixes, audio fixes Copied from Sour's branch. Also a separate change to use separate savefiles. * GB: Try to avoid crashes from buffer overflows * GB: Separate savefiles with linked multiplayer * GB: Add support for faster link speed * GB: Move enum to correct file * GB: Refactor, move serial transfer to function * -Fixed secondary console sometimes running far ahead of the main console when frame counters did not match (e.g because one console had their LCD disabled longer, etc.) This would cause buffer overflows in the audio buffer. -Fixed screen tearing when both consoles are not perfectly in sync (because of the LCD being disabled for a different amount of time, etc.) -Fixed main console not calling PlayQueuedAudio properly mid-frame -Reuse VS Dualsystem code to merge audio/video when possible/simple and moved that to AvMergeUtilities Some visual glitches can appear on the secondary screen (for GB) while rewinding, but this can't really be fixed. * Fixed warning (unused local variable) * Prevent loading single-console save states when in dual-console modes * Disable debugger for VS DualSystem's subconsole. Fixes issues when debugging VS DualSystem games * Code cleanup * Rework solution to disable debugger on second console to improve performance Added InternalRunFrame for nes & gb to avoid checking for the presence of the second console after each cpu instruction * Don't enable the linked GB option by default * Removed unused function * Netplay: Force game to reload after updating emulation settings when connecting to the server (or when the host changes game) This ensures that e.g the GB link cable setting is applied and that the game loads correctly, regardless of the client's link cable settings (otherwise the game could load without the link mode enabled, etc.) --------- Co-authored-by: Sour <mesenemu@gmail.com>
WindowsPreBuildsteps to powershell file..
Hello, thank you so much for creating and sharing Mesen. It is absolutely fantastic. I very much enjoy using it and I wanted to try to give something back.
When building in Visual Studio on Windows 10 at the latest Mesen code - commit fabc9a6 - I get an error about "The file cannot be accessed" while building the
UIproject:Have you ever seen this?
Potential Cause
I think this may be caused by my computer getting confused about the file path for the final
Dependencies.zipzip file. It claims it is not able to find that file.I am using Visual Studio 2022 Community, Version 17.14.23, doing a Release x64 build.
I'm not sure if this is an issue with my setup or if I did something wrong. My steps were:
git clonethe mesen repo to a local foldermesen.slnwith Visual Studio 2022Releaseandx64build configBuild -> Build SolutionMy guess is that this is some difference between system environment variables and powershell's behaviour with paths, or what folders are included in paths.
Fix - Use the full path
I found that if I change the build script to use the full path for the zip file, then the build succeeds.
I went into the
PreBuildWindowscommand and added a batch file%~fpath expansion for the file path.The build then succeeds just fine.
So I wanted to offer this patch to use the full file path.
Move build steps into script
To make viewing and maintaining the build steps a bit easier for humans, I took the liberty of copying the
PreBuildWindowscommands into a powershell script.This would let anyone view all of the steps in one place, e.g. inside a regular Visual Studio editor window, and be able to use regular newlines for spacing, instead of having to edit everything inside a Visual Studio properties window, or use the special

characters for newlines.Just like with PR #79 , I have [set up this branch (including both #79 and this PR) in my own branch in my own copy of the repo, and run the tests with both linux/mac fixes and Windows fixes to prove that it works and the tests all pass.
Thank you for your time.