open-simh/simh

Remove "Visual Studio Projects" subdirectory, projects and solution files

bscottm opened this issue · 0 comments

bscottm commented

Responding to Mark's observation that open-simh accumulated cruft in the "Visual Studio Projects" subdirectory as the result of the windows_build.yml work: Why not remove the entire subdirectory, not just VS 2022 projects (*.vcxproj) and the VS 2022 solution file (Simh.ci.sln)?

I can speculatively understand why @tlhackque added the VS 2022 projects and solution -- sometimes you really don't want to sit and watch Visual Studio upgrade the VS 2008 projects and solution when all you want to do is code. Granted, this only happens the first time the user opens the solution with the added "benefit" that Visual Studio is happy to write the updated project and solution files. And that's how they ended up in the open-simh code base in the first place -- probably by accident, although it's a VS feature.

For the macOS developers, this would be the equivalent of XCode updating its equivalent of a .xcodebuild project file.

Mark: This is not the same as storing .o and .obj files. The .vcxproj files are generated by multiple versions of Visual Studio (2019 and 2017, IIRC.)

Courses of action:

  1. Delete the Visual Studio Projects subdirectory. "You Ain't Gonna Need It" if you have cmake, which is happy to generate VS projects and the open-simh solution across a wide variety of VS versions. Upside: Less to maintain when simulators add/remove files (not very often, but still, it happens.) Downside: This breaks Mark's approach to building Windows executables.

  2. Reorganize the Visual Studio Projects subdirectory, add VS version-specific subdirectories, e.g. "VS2008" for the VS 2008, "VS2022" for VS 2022, etc. Upside: Avoids the project and solution upgrade on first use, avoids accidental additions to the open-simh repo. Downside: Even more stuff to maintain.

  3. Delete the .vcxproj and Simh.ci.sln files. Upside: There's forward compatibility from VS 2008 onward, so no major impact. Downside: Developers have to locate VS 2008 and install it to maintain the Visual Studio Projects subdirectory.

Mark: I know you ensure that a VS 2008 URL is published somewhere in the documentation. Installing VS 2008 is still disk space and overhead just to maintain the Visual Studio stuff when alternatives exist to reduce that overhead and maintenance.