libsdl-org
3.1.10 VisualStudio build doesn't copy all resource files for tests
SDL 3.1.10, using the included Solution file opened under VisualStudio Community 2022 (17.12.4), Rebuilding (for target configuration Debug and architecture x64) includes all test Projects and produces 49 output binaries and some copied resources, but not all resources that the tests require. Attempting to run them results in several 'Error: File Not Found' outputs instead of SDL feature demonstrations.
The exact error messages aren't completely consistenly formatted.
ERROR: Couldn't load icon.bmp: Couldn't open icon.bmp: The system cannot find the file specified.
ERROR: Can't find the file moose.dat !
Specifically, at least the following test projects lack the following resources:
testoverlay: moose.dat
testrendertarget: icon.bmp
testscale: icon.bmp
testsprite: icon.bmp
testyuv: testyuv.bmp
Confusingly, testrendertarget and testscale also require sample.bmp which is copied to the output directory. At a glance, I don't see a difference in how this file is defined as a resource compared to the others.
In the VS Build Output log, I see snippets such as the following:
42>testgl.c 41>Copying moose.dat 43>testfile.c 45>testdialog.c 44>testdraw.c 41> 1 file(s) copied.
Indicating the .dat was copied somewhere, but not to the correct directory.
Incidentally, at least when launched from a PowerShell command line, the loopwave.exe returns to the prompt but does not stop playing the audio, requiring the spawned process to be killed to silence it.
Are you sure you were using the included solution? It doesn't have 49 test binaries, and I run testsprite from it all the time.
I have just
- Checked out a fresh copy of the repo, commit ed2920a (that's had the 3.2 release symbols set)
- Launched VS2022 via the SDL.sln under /VisualC/
- Invoked 'Build Solution'.
Build: 49 succeeded, 0 failed, 0 up-to-date, 0 skipped - Under /VisualC/x64/Debug/ there's 47 .exe and 1 .dll, 126 files in total.
Launching a PowerShell command prompt there, the same 5 executables have the same errors when invoked via said command prompt.
Yes, I believe that's used the CMake integration, but it seems the natural way someone would interact with the repo, I don't think I've caused any non-default behaviours or explicitly chosen this build system for this repo.
It produces that many binaries, and the set of files results in the reported overall unintended behaviour.
Edit:
I see now that this is not the suggested "easiest way to use SDL" as per the included INTRO docs, but it's still a point of inconsistency that some of these test binaries have their resources copied to the output directory and thus can work locally, while some do not, even when the VS Build log is saying that the copies were started & completed.
What are your Debugging settings?
The default settings have the working directory set to $(ProjectDir), and if you look at the build rule for moose.dat in the testoverlay project, it runs copy "%(FullPath)" "$(ProjectDir)\"
Remembering this still existed, I've retested with:
VS2022 17.14.21
SDL3 latest main, commit ff44bad
Build: 56 succeeded, 0 failed, 0 up-to-date, 0 skipped
Under /VisualC/x64/Release/ there's 54 .exe and 1 .dll, 140 files in total.
Invoking testoverlay.exe from that directory I get "ERROR: Can't find the file moose.dat !".
Invoking testsprite.exe results in "ERROR: Couldn't load icon.png: Couldn't open icon.png: The system cannot find the file specified."
Others like testdraw.exe work.
The relevant snippets from VS's Output tab, Build Order:
41>------ Build started: Project: testsprite, Configuration: Release x64 ------
41>Copying icon.png
41> 1 file(s) copied.
41>testsprite.c
41>testutils.c
41>Generating Code...
41>testsprite.vcxproj -> D:\Repos\SDL3\VisualC\x64\Release\testsprite.exe
...
48>------ Build started: Project: testoverlay, Configuration: Release x64 ------
48>Copying moose.dat
48> 1 file(s) copied.
48>testoverlay.c
48>testutils.c
48>Generating Code...
48>testoverlay.vcxproj -> D:\Repos\SDL3\VisualC\x64\Release\testoverlay.exe
I find that \SDL3\VisualC\tests\testoverlay\ contains a copy of moose.dat
Once again, sample.wav and sample.png are present in \SDL3\VisualC\x64\Release\
Invoking testoverlay.exe from \SDL3\VisualC\ has the same result as from the \Release\ subdirectory.
Build -> Clean Solution removes the copy of moose.dat under \SDL3\VisualC\tests\testoverlay\ without simply nuking everything there. So it's putting it there, presumably from \SDL3\test\, and it's clearing it away, but not putting it in the same place as the other .wav and .png resources which would allow the .exe to avoid errors upon invocation with a current working directory of either their current location, or the SDL.sln's location.
Edit:
My Configuration Properties for this Release configuration, for All Platforms, shows as stock values under Debugging (none highlighted in bold). Under General, there's highlighting that seems relevant:
Output Directory $(SolutionDir)$(Platform)\$(Configuration)\
Intermediate Directory $(Platform)\$(Configuration)\
I'm left with the impression that the 'missing' data resource files are copied for the individual Project subbuilds, but not again for the overall Solution build, resulting in the seemingly inconsistent contents of \SDL3\VisualC\x64\Release\.
Yes, the Visual Studio solution copies the data files to $(ProjectDir), which is the working directory of the tests. It's possible to change the working directory of all the tests to the output directory and then change all the copy commands to copy the data there, but that seems unnecessary when everything already works from Visual Studio.
If you think this is important, feel free to create a PR to change this.