#477 Patch to update the MSVC solution + project files to MSVC2022

[Ger Hobbelt]

Ditto as #474 .. #476: a series of patches generated by git; apply in order (as they simply show the work being done as I slowly progressed towards a state that did what I wanted it to do); OR one could simple apply the single FLATTENED patch (name nonumber-blabla-flattened.patch in the attached patch set)

The git repo branch for review is here: https://github.com/GerHobbelt/sdcc/commits/MSVC2022-solution

NOTE: this one is a little hairier than the simple stuff from the previous commits, but overall the result is comparable to what was: the old MSVC solution files hardcoded a C:... search path for the boost libraries, which, of course, doesn't work :-) so I switched that to a relative path set that jumps below the current project base directory into an adjacent boost/.... directory tree containing everything-boost (still gives me the willies, that one, but alas), so we migrate from one hardcoded undocumented path to a relative one pointing to ../boost/ -- I consider that on par with what was.

Anyway, with these project files SDCC now compiles. Don't ask about SDCPP as that one badly breaks, but you can't have it all, I guess.

Added support project files for MOS6502 and PBK hardware devices, which was not present in the old MSVC solution as I believe that one dates back to about 2016 AD -- at least that's where I saw the last bit of work done on it using a swift git tree inspection.

If you don't like this one, of feel nauseous about this particular one, I fully understand. If you don't like, ditch.

(And if you find time to migrate out of SF into some git-based realm 👍 ;-) )

Take care,

Ger Hobbelt

P.S.: FYI: the upgraded solution + projects now dump every scratch object, debug database, etc.etc. file in either <basedir>/obj/... or <basedir>/bin_vc/... directory trees, thus ensuring all produced executables + accompany are together in a single dir, one for debug and one for release builds. We use this rigging over here to ensure there's no clashes between builds, ever, while Microsoft Visual Studio default settings are like a feral flock of city pigeons: shitting all over your dev/source directory tree, making a horrible mess, and I don't particularly like that kind of behaviour. Hence the fatter change set for this "update" to latest MSVC2022. The rigging is set up to support both 32-bit and 64-bit builds, if we find those are both wanted one day.

[John Brandwood]

"Anyway, with these project files SDCC now compiles. "

Hahaha ... we've both been doing the same work in trying to get SDCC to build with Visual Studio, but since I am only interested in getting the compiler itself to build, because I can build the rest in MSYS2, I didn't think that it was something that other people would be interested in.

Anyway, thanks! :-)

FWIW, I'll be raising an issue and sending a patch to the "gala" project, since that also needs a small fix for Visual Studio when compiling SDCC with both the optional "treedec" and "gala" libraries.

[Philipp Klaus Krause]

Did you test these patches? It's been about 26 years since I last used MSCV, so I wouldn't feel comfortable testing them myself. Any SDCC dev that could also test them?

[Philipp Klaus Krause]

I've read through the diffs, and don't see any problem obvious to me, but I'm not familiar with MSVC at all. However, I'm wondering about z80 vs z80a. Why do we have that z80/z80a.vcxproj in our repo?

P.S.: We're still on SourceForge and still use svn. But we do have an official git mirror here now.