I think this should be added to README.git. Without these
explanations, the purpose of Basic.mk and its auxiliary files, and of
their intended usage, is completely unclear.
I believe this was going to Paul. From my side, these explanations
were really helpful.
On to the Basic.mk patch, please see the latest one attached in this email.
After regenerating Basic.mk from .\bootstrap.bat, I tried running it with
both msvc and gcc values for TOOLCHAIN and they both worked fine.
I also tried the 'no resource compiler' case by temporarily renaming
'rc.exe' (msvc) and 'windres.exe' (gcc) to something else so they are
not found on the Windows path, and the build just went through with
no errors and produced non-utf8 GNU Make binaries.
As you will see, in mk/Windows32.mk I used:
ifneq (, $(shell where $(RC) 2>nul))
to tell if a program is on the Windows path. It seems to be working fine
in both cases of 'found' and 'not-found', but I am no GNU Make expert so
please let me know if this is correct.
A little inconsistency is that in build_w32.bat I didn't implement a check
for 'rc.exe' because I assumed it's always going to be in the Windows
path if the compiler 'cl.exe' is, but in mk/Windows32.mk I did implement
the check even for 'rc.exe' - I can add the check in build_w32.bat to be
consistent in a next update, it should be easy.
Also just checking - the configury approach, when building for Windows
host, can't be used with msvc or tcc, right? It needs to find gcc
targeting Windows, and therefore checking for windres (already
implemented) should be sufficient, right?