Build module with MingW (and other compilers) with Ubuntu host on our GitLab server.

[pheest]

Built the ADURL module in this environment.

[ericonr]

Hi!

Should this PR be merged into upstream? The description implies it's specific to your environment.

[pheest]

Hi,

This is so long ago, I am struggling to remember the details.

The PR is about use of the MingW (https://www.mingw-w64.org/) toolset that builds for Windows use on a Linux host.
I think this capability has value outside of the organisation, but I'm not sure how much.

The GitLab environment is only relevant here in that I think it did not then have a native Windows toolchain - but now it probably does.

Hope this helps. If you prefer to discard the PR, I am OK with that.

[ericonr]

The GitLab environment is only relevant here in that I think it did not then have a native Windows toolchain - but now it probably does.

That's fair! I think it's just a matter of documenting the changes in a generic way.

From what I can see of this PR, it also removes a lot of Windows code that's probably still needed when using MSVC... Was that intentional?

I think this PR can be left open if you're willing to rework it to support native and mingw builds; otherwise, it should be closed.

[pheest]

I'm not aware of having removed any Windows code that is needed when using MSVC.
Can you point me to what leads you to say that?

Clearly the native build is more important and - to my knowledge - has not been broken at all.

[pheest]

OK, I believe you are referring to the removal of the build/windows subfolder.
It contains code (for Windows only) that could be used to debug/trace the GraphicsMagick library (by the developers thereof).

It is not needed for use of the library by either MSVC or MingW.
But I could not build the folder code with MingW.

It had been inappropriate to build the ADSupport module for normal use using the debugging code.

I judge it appropriate to remove the folder from use by the makefile.

However, my removal of the folder itself was unnecessarily ... brusque.
I have reverted that change.

[henriquesimoes]

I think this PR can be left open if you're willing to rework it to support native and mingw builds; otherwise, it should be closed.

@pheest, I'm afraid you haven't answered this part of Érico's comment. Would you be interested in reworking it even though you now have native compiler support on your end?

[pheest]

I am sorry for not being sufficiently explicit.

This pull request fully supports both native (VS) and MingW builds.
I have not (at any time) removed either capabability, but have made the MingW build work.

I did (inappropriately) remove some files that were not used by the normal build, but could be used for internal debugging (on Windows only). These I have restored.

To my knowledge, no re-work is required.
Disclaimer: I last tested this in 2022.

[henriquesimoes]

To my knowledge, no re-work is required.

Thanks for clarifying. Misunderstanding from my part.

Disclaimer: I last tested this in 2022.

Okay. It would be interesting to have someone double-check if nothing broke it since then. I don't have a machine for testing it now. From ADSupport side, little has changed since 2022 as far as I can see. Hopefully, it should be still in good shape.

[pheest]

I was aware of an issue with MingW that the (default) win32 threading model did not work well.
https://forum.openmpt.org/index.php?topic=6822.0 seems to refer.

In my 2022 build for this, I have used the Posix thread model.

I don't know whether this issue has since been addressed in the MingW toolchain.
It would be interesting to find out.