I side-stepped this issue by copying .\WinRel\gnumake.exe
to the top-level folder and running this instead:
.\gnumake.exe -f Basic.mk TOOLCHAIN={msvc(default),gcc}
which worked.
I implemented the changes in Basic.mk and mk\Windows32.mk
(which is being sourced by Basic.mk) and they seem to be working
fine: I got UTF-8-working executables in WinRel\gnumake.exe
and GccRel\gnumake.exe for the two options of TOOLCHAIN
respectively. Note that there is no "tcc" option here, in contrast
to the build_w32.bat file approach.
However, when trying to prepare the new patch I realized that
Basic.mk is an untracked file which is listed in .gitignore, so how
would you like me to show you these latest changes?
On Tue, 16 May 2023 at 19:05, Costas Argyris <costas.argy...@gmail.com>
wrote:
> Thanks for that info - I tried doing exactly as you said and I'd say I'm
> almost there, except for the final link step:
>
> When running
>
> .\WinRel\gnumake.exe
>
> (with or without -f Basic.mk, doesn't matter)
>
> it seems that the final executable is attempted to be created in
> the exact same file that started the build, leading to the error:
>
> LINK : fatal error LNK1104: cannot open file 'WinRel\gnumake.exe'
>
> I tried taking a quick look at how the output directory is decided,
> but it's not so easy because apparently Basic.mk sources other
> platform-specific files under the 'mk' folder, mk\Windows32.mk
> in this case, and it's not so easy to tell what is happening there
> with the OUTDIR variable. The variable that appears to be
> honored is
>
> release_msvc_OUTDIR = ./WinRel/
>
> but that seems to be unused in the file (?).
>
> There is even this comment in mk\Windows32.mk that seems
> relevant:
>
> # I'm not sure why this builds gnumake rather than make...?
> PROG = $(OUTDIR)gnumake$(EXEEXT)
>
> Before I dig deeper into it, am I missing something obvious?
>
> I could try and change the output dir, but afaict this was
> supposed to work as-is.
>
> On Mon, 15 May 2023 at 19:14, Paul Smith <psm...@gnu.org> wrote:
>
>> On Mon, 2023-05-15 at 17:48 +0100, Costas Argyris wrote:
>> > As I have said before, I wasn't successful in getting the Basic.mk
>> > approach to work on Windows, as I was getting various errors all
>> > over the place. They started with CC being undefined, but even
>> > after I defined it to 'gcc' this just took me to various link errors,
>> > at which point I thought that this approach is not really maintained.
>> > That was in contrast with the other two approaches on Windows
>> > host, namely configure and .bat file, both of which worked as
>> > expected.
>>
>> I think I tried to say before, but probably failed to be clear, that
>> Basic.mk is used _in conjunction with_ one of the alternatives to
>> running configure.
>>
>> By that I mean you FIRST have to use one of the alternatives to running
>> configure, THEN you can use Build.mk. The Basic.mk framework doesn't,
>> in particular, set up config.h etc.
>>
>> So, the following recipe works for me; first:
>>
>> .\build_w32.bat
>>
>> This sets up config.h and copies the Basic.mk file to be Makefile so
>> that it's available for GNU make to use.
>>
>> .\WinRel\gnumake.exe
>>
>> This invokes the just-built GNU Make and uses the Makefile copy of
>> Basic.mk (of course you can use .\WinRel\gnumake.exe -f Basic.mk
>> instead if you prefer).
>>
>> By default, Basic.mk uses Visual Studio as the compiler, and it expects
>> the invoking shell has set up MSVC using vcvarsall or whatever. If you
>> set TOOLCHAIN=gcc on the make command line it should use GCC. I admit
>> I haven't tried this one recently.
>>
>> > So, can this feature proceed without changes in Basic.mk?
>>
>> It's fine with me if you want to submit a patch that doesn't provide
>> these updates. I can add them myself, or not.
>>
>
