Shouldn't check in CMake-generated MSVC files

[maxim-zhao]

The contents of the Windows directory seem to be the auto-generated files made by CMake. These should be generated as part of the build, by running CMake:

cmake . -B windows -G "Visual Studio 17 2022" -A "x64" --fresh

for x64, and

cmake . -B windows -G "Visual Studio 17 2022" -A "Win32" --fresh

for x86. (Or omit -B windows to generate in the root, as you're not going to check them in anyway.) Both of these seem to produce some different files than what's already there, though... to be honest, I'm not sure what the intended difference is between the three Windows builds anyway.

[vhelin]

What's in the "windows" directory is something that has been done with Visual Studio AFAIK. I personally have never used cmake under pure Windows (only in Cygwin).

That said I don't understand this issue at all. :) For reference: I know very little what cmake does. My understanding is that it generates makefiles from CMakeLists.txt etc...

[vhelin]

We have three Windows builds AFAIK:

• x86
• x64
• MSVC (different compiler here, not the same as in x86 and x64 builds)

Someone wiser can correct me if I'm wrong. :)

[vhelin]

For reference: I've maintained the solution and project files under the "windows" directory manually. So if there are changes in CMakeLists.txt then I open Visual Studio and edit the solution and project files accordingly. Is this an issue?

[maxim-zhao]

It's certainly not the intention :) CMake is a makefile generator, it can make VS projects as well as makefiles and Ninja files and more. The windows directory files are named such that I can tell they were originally generated by CMake, hence why I think they ought not to be there, the same as you ought not to check in any generated makefiles.

The three Windows builds seem to all be using the same compiler, but targeting 32 and 64 bit between them. The comments in the Azure files seem a bit confusing as they mention .net and GCC, and use neither...

Broadly, I think you should have CI builds that exercise the parts you are interested in maintaining and run the tests. Also producing artifacts for download might be nice for some users, especially on Windows.

[vhelin]

Haha, looking back at this

http://www.villehelin.com/wla-win32.html

I think you made the original Visual Studio solutions/project files for WLA DX back in the day, and I've just kept on maintaining them.

The difference between makefiles and Visual Studio solutions is that makefiles are system dependent while Visual Studio solutions are the same on every Windows computer, I think. I'm not 100% sure, but I think that's the case. So Visual Studio solutions should be remade/updated only when there are new .c files added to the project, or old ones removed.

Also I'd like to keep Visual Studio solution/project files in the Git for people who don't have CMake. Just like we have amiga makefiles there for people who don't have Python (on Amiga - is there Python for Amiga?). I can continue maintaining them manually, no problem with that.

Looking at the Azure build logs, MSVC build seems to use CMake and then MSVC compiler while x86 build uses the existing Visual Studio solution and also MSVC compiler? Are we just testing two different ways of building WLA DX on Windows here? Not sure what's the origin of the MSVC build script, but I suspect there was a GitHub issue about adding it...

And yeah, the comments in the Azure Pipelines build scripts are totally incorrect. Perhaps because I took them from the Internet and just modified them and didn't touch the comments...

About artifacts, all the Azure builds generate artifacts already:

1. Click on these icons:

2. Click on "Published"

3. Click on "Download artifacts"

[maxim-zhao]

The current files are not from my 20-year-old efforts, they are definitely generated by CMake - apparently with Visual Studio 2015. Visual Studio ships with CMake, and tries to railroad you into using it these days, so I don't think it's a concern to ship without it. I've been building WLA DX for years since the CMake migration, without realising these files were even there :)

I may have a go at tidying things up a bit, but as I don't have Azure pipelines, I may have a few guesses there. Basically, the Windows build can be very similar to the Linux and MacOS ones - they could almost be identical.

[vhelin]

If you can fix this "issue" so that WLA DX can be built with plain Visual Studio 2010 (I want to keep Windows XP support here) without a Visual Studio solution in GitHub then go for it. :) Otherwise I see the removal of Visual Studio solution as a downgrade as it makes WLA DX to require a new Visual Studio...

[maxim-zhao]

I'll have to see if I can dig out an old environment like that. I think targeting MinGW is more often used for old Windows.

[StarWolf3000]

To keep Windows XP support for the binaries, you can use the regular GNU Autotools and Makefile (and skip CMake entirely) and use MSYS2's MINGW32 (based on mingw-w64) environment to build (package prefix mingw-w64-i686-).

There is a GH Action available that provides access to the MSYS2 environment for CI: https://www.msys2.org/docs/ci/

[vhelin]

The point of having Visual Studio solution/project files in the GitHub is that people can easily make their own builds of WLA DX. It's easy to install Visual Studio and click on the build button. And currently you can do that on Windows XP with Visual Studio 2010.

I don't know if MSYS2 works on Windows XP, but there you need to issue commands in a shell that's that exponentially more difficult for many people. :)

[StarWolf3000]

They have eliminated Windows XP support quite some time ago as host platform (I think you need at least Windows 7 to install the environment), but you can still build programs that can run on it.

[maxim-zhao]

Recent Visual Studio is almost preferring CMake over project files. You "open" the source directory and it just works.

However, CMake is useful for centralising the build process across platforms. It's useful to be able to add something once and have it build on everything - except maybe Amiga - with CMake . && cmake --build . or something close to that.

I still intend to make the CI do more of what you want, I just haven't had much time to spend on it. The msys2 approach seems easiest and CMake seems to support that well.

[maxim-zhao]

I made a quick demo of how it works. I jumped through some hoops to get a release build, by default it builds in x64-debug mode.

https://youtu.be/kCjJxb3vWCA

[maxim-zhao]

I'm currently struggling to get to terms with Azure Pipelines, it seems mostly simple but it's non-trivial to sign up for it to test anything I do. It claims to have msys2 installed but some package installation is likely needed.

[vhelin]

I made a quick demo of how it works. I jumped through some hoops to get a release build, by default it builds in x64-debug mode.

https://youtu.be/kCjJxb3vWCA

Looks relatively easy! But which Visual Studio is this?

[maxim-zhao]

Current :) but I think it's the same back to either 2017 or 2019. I had a little try with VS Code but that requires you to install compilers separately, which is maybe too far removed for casual users.