Thanks for the report. There are clearly things that can be improved here.

With the current state, you still can override CC and friends by passing it as an option to the make invocation: make CONFIG=mingw64-win32 CC=..., but not with environment variables. I think taking your suggestions makes sense here. It probably is also useful for all other CONFIG=.

Are you aware that we also provide release tarballs with an Autotools based build system? Could this be preferable for your use case? Sadly, Autotools currently cannot be used to build from the repository directly (I hope to fix this in the future).

I also see you are using another patch which allows overriding pkg-config (https://github.com/m-ab-s/mabs-patches/blob/master/openmpt/0001-make-try-using-PKG_CONFIG-if-provided.patch). I think this would also be clearly useful for us.

Your suggestion does not work though: CC and related variables have default values if not set by any other means, thus the make or function always considers them set.

I implemented something that hopefully works in r17547 (trunk) and r17548 (0.6):

We unset these builtin variables before loading the config (which always wants to set them). That way, we can assign them via CC ?= in build/make/* and get the desired result in all cases.

I also see you are using another patch which allows overriding pkg-config (https://github.com/m-ab-s/mabs-patches/blob/master/openmpt/0001-make-try-using-PKG_CONFIG-if-provided.patch). I think this would also be clearly useful for us.

Implemented in r17549 (trunk) r17550 (0.6).

Can you please verify that what I implemented does indeed work for you?

Are you aware that we also provide release tarballs with an Autotools based build system? Could this be preferable for your use case? Sadly, Autotools currently cannot be used to build from the repository directly (I hope to fix this in the future).

For openmpt, my build script pulls the latest tag matching libopenmpt-* from https://github.com/OpenMPT/openmpt.git (just so it doesn't have to worry about svn), so it technically uses a release, but a tag of it though.

As a side question, does the master branch of that mirror correlate to the trunk? I do see that the git branch contains the revisions you mentioned already and has the same layout as the latest libopenmpt-* tag https://github.com/OpenMPT/openmpt/tree/libopenmpt-0.6.4.

Your suggestion does not work though: CC and related variables have default values if not set by any other means, thus the make or function always considers them set.

Seems you have found out my lack of autotools/makefile related skills, most of that was based on suggestions from a stackoverflow post

Since I use the tag version, I instead used a cherry-picked version of your revisions https://github.com/1480c1/openmpt/commit/2a02d3152 and https://github.com/1480c1/openmpt/commit/a6b824fe2

Using those two, compilation with just the env variable set with CC and CXX not set on make results in:

[AR] bin/libopenmpt.a
x86_64-w64-mingw32-g++.exe: error: unrecognized command-line option '--start-no-unused-arguments'
x86_64-w64-mingw32-g++.exe: error: unrecognized command-line option '--end-no-unused-arguments'
make: *** [Makefile:1712: bin/libopenmpt.dll] Error 1
make: *** Waiting for unfinished jobs....
+ [[ -n -j8 ]]
+ make -j1 install PREFIX=/local64 CONFIG=mingw64-win64 AR=ar STATIC_LIB=1 EXAMPLES=0 OPENMPT123=0 TEST=0 OS=
[LD] bin/libopenmpt.dll
x86_64-w64-mingw32-g++.exe: error: unrecognized command-line option '--start-no-unused-arguments'
x86_64-w64-mingw32-g++.exe: error: unrecognized command-line option '--end-no-unused-arguments'
make: *** [Makefile:1712: bin/libopenmpt.dll] Error 1

Using make -j8 install PREFIX=/local64 CONFIG=mingw64-win64 AR=ar STATIC_LIB=1 EXAMPLES=0 OPENMPT123=0 TEST=0 OS= 'CC=ccache clang' 'CXX=ccache clang++' to set them does succeed, so I will just go ahead and set them on make.

I did go ahead and try the master branch, and I seem to get some errors with it, but I am assuming those are unrelated to this issue, I will try to see if that's a configuration issue or something and open a new issue for it

[CXX] common/mptFileType.cpp
clang++: warning: argument unused during compilation: '-mconsole' [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-mthreads' [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-mconsole' [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-mthreads' [-Wunused-command-line-argument]
In file included from common/ComponentManager.cpp:11:
In file included from common/stdafx.h:68:
src/mpt/check/libc.hpp:38:10: error: invalid token at start of a preprocessor expression
#if (_MT != 1)
         ^

As a quick note to append, the error does not show up with https://github.com/OpenMPT/openmpt/tree/OpenMPT-1.30, so I could also use that since it seems to be similar to the libopenmpt-* tags

For openmpt, my build script pulls the latest tag matching libopenmpt-* from https://github.com/OpenMPT/openmpt.git (just so it doesn't have to worry about svn), so it technically uses a release, but a tag of it though.

That's fine. Using a release (or at least a release branch) is strongly preferred as opposed to trunk/master.

As a side question, does the master branch of that mirror correlate to the trunk? I do see that the git branch contains the revisions you mentioned already and has the same layout as the latest libopenmpt-* tag https://github.com/OpenMPT/openmpt/tree/libopenmpt-0.6.4.

yes, git master is the same as svn trunk.

And we also have svn and git branches for stable release branches. We do not make patch releasesfrom trunk but only from release branches, thus ...

Since I use the tag version, I instead used a cherry-picked version of your revisions https://github.com/1480c1/openmpt/commit/2a02d3152 and https://github.com/1480c1/openmpt/commit/a6b824fe2

... you should have cherry picked the patches from branch OpenMPT-1.30 instead: https://github.com/OpenMPT/openmpt/commit/022865b21bad4f673048bdf06318c3dd50f94164 / https://github.com/OpenMPT/openmpt/commit/9e85fad054565a57734fc722c67878ec8cbfdcf2 . Does not matter for the pkg-config part, but the CC part is different between 0.6 and trunk.

As a quick note to append, the error does not show up with https://github.com/OpenMPT/openmpt/tree/OpenMPT-1.30, so I could also use that since it seems to be similar to the libopenmpt-* tags

Yes, use that branch please (at least until 0.6.5 is released, then continue from there with stable releases).

I did go ahead and try the master branch, and I seem to get some errors with it

No need for an extra report, I will look into it. I have a MSYS2 setup myself, so it should be trivial to reproduce and fix.

Also note that our mirroring script takes some time, so svn revision will not immediatly show up in git. Takes roughly 30 minutes usually.

Yes, use that branch please (at least until 0.6.5 is released, then continue from there with stable releases).

Perfect, I will go ahead and switch to that branch instead

No need for an extra report

Okay, if you need any other info, I can provide it

No need for an extra report
Okay, if you need any other info, I can provide it

Should be fixed in r17551 .

I'll also look into a way to only pass compiler options that clang understands.

I'll also look into a way to only pass compiler options that clang understands.

Turns out I already did implement that half-way. If you additionally pass MINGW_COMPILER=clang, it will now only pass clang-compatible compiler and linker options. Requires r17557 .

r17553 cleans up another clang warning.

MINGW_COMPILER=clang

Added locally, thanks!

Well, and turns out my fix also does not work because it requires make 3.82, which Apple for some reason still does not ship 12 years later. r17561 adds back support for earlier make versions, which makes the fix a good bit more ugly, but there is nothing I can do about that.

I also added GitHub workflows that test-build with your toolchain configuration, so that we do not accidentally break that again in the future.