minor cleanup of MinGW-related scripts

[FyiurAmron]

(includes removal of ancient Ubuntu 14 stuff)

[FyiurAmron]

CC @DomClark @messmerd @tresf , if any of you can review/merge this I would be really grateful. I'm aiming at streamlining and revamping the MinGW/MSYS builds as much as possible here, step by step. Any comments are welcome.

[tresf]

Thanks for cleaning up the old files. I've requested a few minor changes.

[tresf]

@FyiurAmron thanks. One more thought, and this isn't required, but how do you feel about parameters? For example, once #7252 is merged, we'll be able to provide some debugging commands for makensis (and friends), but only via WANT_DEBUG_CPACK=true. In your experience, how would you ideally provide these to a mingw scripted build?

[FyiurAmron]

@tresf my first guess would be to just pass that via CMAKE_OPTS - the MinGW script already consumes that env var and it's ubiquitous in our CI/helpers, so I'd just append -DWANT_DEBUG_CPACK=ON to $CMAKE_OPTS one way or the other (e.g. CMAKE_OPTS="-DWANT_DEBUG_CPACK=ON $CMAKE_OPTS" or CI's env or whatever the exact use case would be`), that should work well I think.

_{I don't know the full picture so I might just be rambling nonsense here, though :D}

[tresf]

@tresf my first guess would be to just pass that via CMAKE_OPTS

Perfect.

[DomClark]

IMO the MinGW wrapper script would ideally forward its arguments to CMake, so it can be used as a drop-in replacement. For macOS and MSVC builds (and Linux in #7316), we currently invoke CMake with a command like the following: cmake -S . -B build -DFOO=BAR. The build_mingw.sh script currently hardcodes an older command signature where the source directory is passed as a plain argument, and the build directory is assumed to be the current directory. It would be nice to be able to write ./cmake/build_win32.sh -S . -B build -DFOO=BAR, as opposed to the current mkdir build && cd build && CMAKE_OPTS="-DFOO=BAR" ../cmake/build_win32.sh.

[messmerd]

@DomClark Maybe we could perform the tasks of the build script in the CMake toolchain file instead, and then just use

cmake -S . -B build -DFOO=BAR --toolchain "./cmake/toolchains/Ubuntu-MinGW-W64-${{ matrix.arch }}.cmake"

[DomClark]

That's a possibility too. IIRC in the past the arguments have been in favour of maintaining scripts to automatically determine the toolchain file, in order to make things "just work", at which point it doesn't really matter where those tasks go. But MSVC users need to specify the toolchain themselves anyway, and the average user isn't going to be cross-compiling with MinGW, so perhaps the scripts don't offer too much benefit.

[tresf]

But MSVC users need to specify the toolchain themselves anyway

Agreed, this really makes it feel redundant.

the average user isn't going to be cross-compiling with MinGW

I'm not sure what "the average user" is, but I do agree that it's trivial to just add this to our documentation. In the past, when regular users would compile the software themselves, it was because we lacked a nightly release. Now we have a nightly release, this is much less likely to be used... so I too believe this script to be overkill.

Note, this script has been around since '08, so it's been kept around mostly as a tradition only: d3516cd.

Back then -- prior to CMake -- the compiler flags were much more complex to provide at the terminal.

[FyiurAmron]

@DomClark updated that, and did that for pure Linux build as well to match. Works like a charm.
@messmerd spot-on.
@tresf I concur. I removed the shell scripts, and everything still works like a charm, with just the toolchain files. IMVHO this was an overkill like Dom said: MSYS2 works perfectly without toolchain files (I'm using #7283 as a proof-of-concept for that, it works locally without any additional config for me), and MinGW Linux-to-Windows cross-compilation outside of CI is really an edge case... and even then it's still a one-liner that can be copy-pasted from the CI script if needed.

Anyway, I'd say a re-review is in order :)