BizHawk
BizHawk copied to clipboard
TASEmulators
dlls in assets instead of output makes it so when updating a dll you have to rebuild emuhawk
Previously this wasn't necessary, so it's a development cycle regression. Please find a way to make the contents of assets be items in the project subject to dependency checking so they will be re-copied as needed, rather than freshening them as a post-build event
Not sure what you mean by:
make the contents of assets be items in the project subject to dependency checking
Each core's build scripts simply need to be changed so that they copy to both /Assets and /output.
- ~~managed Hawk cores~~ N/A
- ~~Virtu~~ (outputs to
/References) - [x] Waterbox (host, BSNES, Genplus-gx, the 6 Nyma cores, and the other 6 cores)
- Unmanaged cores
- [x] Cygne (
Makefileand.vcxproj) - [x] Gambatte (
Makefileand.vcxproj) TASVideos/gambatte-speedrun#21 - [x] Handy (
Makefileand.vcxproj) - ~~MAME~~ unreleased
- [x] mGBA (
Makefiles) TASVideos/mgba#5 - [ ] MSXHawk
- [ ] Mupen64Plus + plugins (
.vcxproj, currently uses/Assetsas<OutDir/>) - [ ] Octoshock (
.vcxproj) - [x] QuickNes (
Makefileand.vcxproj)
- [x] Cygne (
- erase the csproj part that copies the files
- add a part that makes the csproj know those files exists
- those files are "built" by copying them if they are out of date.
- if needed add an entirely separate project for the assets which all the other projects can depend on
Otherwise, besides updating all the build scripts to copy a file two places (sloppy) anything which updates an asset and nothing else (e.g. an update from git or manually applied patch) won't know to "rebuild" the assets (that is, copy them to the output directory)
I can't believe I'm having to explain this.
Can you please state, for the record in this thread, WHY you made the change to use the assets directory instead of solely the output directory?
those files are "built" by copying them if they are out of date
This is the current behaviour. Assets are copied on every build because the assets target is in BizHawk.Common.csproj. I believe the only exception is if you're building from VS with incremental builds enabled and trigger a build without making any changes, in which case the whole build including the assets target is skipped. Now if VS has messed with incremental builds and broken the target, that's another problem entirely.
anything which updates an asset and nothing else (e.g. an update from git or manually applied patch) won't know to "rebuild" the assets
How exactly is changing MSBuild project files going to fix this? You'd still need to run MSBuild. And if you're going to do that, why do anything when it works as-is?
Can you please state, for the record in this thread, WHY you made the change to use the assets directory instead of solely the output directory?
Having MSBuild use files from the output dir as inputs was confusing and error-prone, and it being under .gitignore didn't help. The /output dir, which semantically was for only outputs, now truly contains only outputs, and as a side-effect is truly ephemeral.
- emuhawk checks if common is dirty. common doesnt think it's dirty because it doesnt know it has assets as dependencies. You are wrong. Those files are built, by copying them, ONLY WHEN COMMON builds, regardless of whether they are out of date. they may be out of date but if common doesn't build then the assets won't get copied.
- moot, since it doesnt work as-is
- having msbuild use files in the output directory worked fine for years. Please elaborate your rationale with "error-prone". I don't care if you were confused by it.
With 8e7f171ae9b4e4b9106a86447d2def278f0a6070 the bare minimum requirement of waterbox development is functioning again. That doesn't mean all of this extra copying is great, of course.
Can we just revert this new "feature" that was pushed with no trace of prior discussion or proof of "confusion and error-proneness"? I don't remember a single dev that was confused by it being send to output. And I don't remember any tickets describing the errors it caused. And I don't even see devs supporting the change and going "ah! okay then!".
@YoshiRulz is your stance "fuck you all and deal with what I decided"?
Once those PRs are merged, only Mupen and Octoshock will be left. I'll do Mupen later once the rumble stuff is done. I wasn't able to build Octoshock, something about needing Windows 8.1 SDK when I had the Windows 10 SDK.
The copying being skipped with incremental builds should be fixed by 443c9830b.
is your stance "fuck you all and deal with what I decided"?
Basically, yeah. I'm in the build purity cult now.
If the dependencies are tracked correctly (and it seems they are now due to that commit) then why do we need unmanaged cores to copy to output? The typical workflow is to build the unmanaged core and then run emuhawk from visual studio, which will make the msbuild logic detect that an asset is dirty and copy it to output.
That may be the typical workflow, but I can imagine someone wanting to iterate on a core without having the BizHawk solution open as well. IIRC @CasualPokePlayer or someone was doing that with Gambatte, and they kept testing the same build from /output and wondering why their changes had no effect.
OK fine but you better hope we never find another reason why this asset copying bullshit is upsetting workflows or else I'll revert it myself and it will be no big deal because these cores will all be copying to output already.
I repeat. If you have to copy things, then the original goal is defeated, because you're back to having it sent to output like before, just with a ridiculous extra magic that solves nothing for no one. Keep in assets only things we don't build, or make it recognize the built stuff in assets without moving them around. Why is this so hard to comprehend?
He did make it (visualstudio/msbuild) recognize the built stuff in assets without moving them around. He's only copying them to output also because some people run emuhawk from there directly instead of in visualstudio. I'd be fine with telling them not to do that, but I don't see the harm in the extra copies.
That may be the typical workflow, but I can imagine someone wanting to iterate on a core without having the BizHawk solution open as well. IIRC @CasualPokePlayer or someone was doing that with Gambatte, and they kept testing the same build from
/outputand wondering why their changes had no effect.
That was a problem on my side for a while yes, and even then, running EmuHawk in Visual Studio did not copy Assets to output, and I was only able to solve it by manually copying from Assets to output (if I understand right, that part isn't needed anymore for Visual Studio). Being able to do core builds without rebuilding EmuHawk every time is much faster for development (when changes are purely on the core side without any need for frontend updates).
I'm not going to inject this "feature" into mame build scripts. And I'm not planning to add an extra script that just does the copying. Because it's ridiculous extra magic no one ever asked for. If he can't make it uniform for all cases, then this is a bad idea altogether.
The extra copy to /output is only there as a convenience in case you modify and rebuild the core but forget to rebuild EmuHawk. You don't need to put it in MAME.
Have we suddenly decided that it's meant to be inconsistent? Man it's getting worse...
That may be the typical workflow, but I can imagine someone wanting to iterate on a core without having the BizHawk solution open as well. IIRC @CasualPokePlayer or someone was doing that with Gambatte, and they kept testing the same build from
/outputand wondering why their changes had no effect.
I actually think that is pretty useful. In my occasional dabbling in C++ I would have found this pretty convenient, since when I'm making a lot of changes to the core it gets pretty tedious to copy it over by hand each time.
You would never have to copy it over by hand. It would have simply built to the right spot in the first place. There was only a brief period of time when files were not built to the right spot, and as of today that period of time has ended. We're only discussing his because that brief period of time happened. Before then it worked fine, and after then it works fine.