Re: [PATCH] Use UTF-8 active code page for Windows host.

[Costas Argyris]

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 
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  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.
>>
>

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

[Dmitry Goncharov]

Follow-up Comment #6, bug #64185 (project make):


> The error is caused not by the else in the recipe, but when adding the
$(warning ...) statement immediately preceding the make else.



all:
ifdef blah
junk:
else
else
endif


Here, the parser sees rule 'all:' and begins its search for recipe lines of
'all:'. Then the parser sees 'ifdef blah'. 'blah' is not defined and the
parser
ignores the following line, which is 'junk:'. Then parser reads '\telse' and
takes
it as a recipe of 'all:'. Because the parser took one of the two elses as a
recipe,
there is no complain about extra elses in a conditional.


all:

$(info hello)
ifdef blah
junk:
else
else
endif


Here, $(info hello) ends the search for recipe lines of 'all'.
By the time the parser reads 'ifdef blah' it is no longer looking for recipe
lines. The parser then ignores 'junk:', because 'blah' is not defined and
treats '\telse' as a conditional directive.
The parser then complains about two elses in conditional.

This all boils down to the fact that the parser ignores code in the branches
not
taken and does not know that 'junk:' begins a new rule.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Paul Smith]

On Wed, 2023-05-17 at 12:47 +0100, Costas Argyris wrote:
> 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?

The file to be changed is Basic.mk.template

Sorry I have been out of touch this week; I likely will not have much
time until the weekend.  I'm looking forward to the patch though!

For your initial question I understand the issue and I'm not sure how
it works for me I'll have to try it again.  It does seem wrong that we
replace the running instance of make; that can never work on Windows
(it works on most POSIX systems).

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Costas Argyris]

Here is the patch with the Basic.mk.template and mk/Windows32.mk
changes.I tried to keep most of the changes in the Windows-specific
file, but something had to happen in the general one as well, as far as
I could tell.

I deliberately sent only the changes relevant to the Basic.mk approach
here to facilitate review.

The changes are working as far as I can tell, with both

.\gnumake.exe -f Basic.mk TOOLCHAIN=msvc

and

.\gnumake.exe -f Basic.mk TOOLCHAIN=gcc

(and without TOOLCHAIN at all, of course, defaulting to msvc)

First I had to run

.\bootstrap.bat

to re-generate Basic.mk after changing Basic.mk.template and mk/Windows32.mk

These produce UTF-8-supporting gnumake.exe binaries in their corresponding
WinRel and GccRel folders.

As you will see, I haven't implemented checking if windres is available on
the path for the TOOLCHAIN=gcc case, as I have never come across a
case where a gcc distribution for Windows doesn't include windres (in all
cases I have seen, it gets distributed with binutils because it needs the
assembler and linker that are not part of gcc, and windres is part of
binutils
so it's also there).

Tcc is not supported with the Basic.mk approach anyway, so no need to
worry about the fact that it doesn't ship with windres.

MSVC always has its own resource compiler available.

If you still need the check for windres for the gcc case, please let me
know.

On Wed, 17 May 2023 at 14:10, Paul Smith  wrote:

> On Wed, 2023-05-17 at 12:47 +0100, Costas Argyris wrote:
> > 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?
>
> The file to be changed is Basic.mk.template
>
> Sorry I have been out of touch this week; I likely will not have much
> time until the weekend.  I'm looking forward to the patch though!
>
> For your initial question I understand the issue and I'm not sure how
> it works for me I'll have to try it again.  It does seem wrong that we
> replace the running instance of make; that can never work on Windows
> (it works on most POSIX systems).
>


Basic-mk.patch
Description: Binary data

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Costas Argyris]

Actually I think windres should be optional here too,
even if it is just for being consistent across all build
approaches.

If you agree, please let me know of what would be a
good portable way to check if windres is on the path
from within a Makefile (mk/Windows32.mk I guess).

>From a quick search there appear to be many ways
to do this, but some of them are GNU Make-specific,
and I believe these Makefiles (Basic.mk and those
included by it) have to work with any Make, not just
GNU Make.

Also note that this can be a Windows-specific way,
possibly involving 'where windres' or 'windres --version'.
But I'm not sure how this is best done from within a
Makefile that has to be processed on Windows by
any Make program.

On Wed, 17 May 2023 at 19:34, Costas Argyris 
wrote:

> Here is the patch with the Basic.mk.template and mk/Windows32.mk
> changes.I tried to keep most of the changes in the Windows-specific
> file, but something had to happen in the general one as well, as far as
> I could tell.
>
> I deliberately sent only the changes relevant to the Basic.mk approach
> here to facilitate review.
>
> The changes are working as far as I can tell, with both
>
> .\gnumake.exe -f Basic.mk TOOLCHAIN=msvc
>
> and
>
> .\gnumake.exe -f Basic.mk TOOLCHAIN=gcc
>
> (and without TOOLCHAIN at all, of course, defaulting to msvc)
>
> First I had to run
>
> .\bootstrap.bat
>
> to re-generate Basic.mk after changing Basic.mk.template and
> mk/Windows32.mk
>
> These produce UTF-8-supporting gnumake.exe binaries in their corresponding
> WinRel and GccRel folders.
>
> As you will see, I haven't implemented checking if windres is available on
> the path for the TOOLCHAIN=gcc case, as I have never come across a
> case where a gcc distribution for Windows doesn't include windres (in all
> cases I have seen, it gets distributed with binutils because it needs the
> assembler and linker that are not part of gcc, and windres is part of
> binutils
> so it's also there).
>
> Tcc is not supported with the Basic.mk approach anyway, so no need to
> worry about the fact that it doesn't ship with windres.
>
> MSVC always has its own resource compiler available.
>
> If you still need the check for windres for the gcc case, please let me
> know.
>
> On Wed, 17 May 2023 at 14:10, Paul Smith  wrote:
>
>> On Wed, 2023-05-17 at 12:47 +0100, Costas Argyris wrote:
>> > 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?
>>
>> The file to be changed is Basic.mk.template
>>
>> Sorry I have been out of touch this week; I likely will not have much
>> time until the weekend.  I'm looking forward to the patch though!
>>
>> For your initial question I understand the issue and I'm not sure how
>> it works for me I'll have to try it again.  It does seem wrong that we
>> replace the running instance of make; that can never work on Windows
>> (it works on most POSIX systems).
>>
>

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Paul Smith]

On Wed, 2023-05-17 at 22:55 +0100, Costas Argyris wrote:
> From a quick search there appear to be many ways
> to do this, but some of them are GNU Make-specific,
> and I believe these Makefiles (Basic.mk and those
> included by it) have to work with any Make, not just
> GNU Make.

No; those makefiles can only work with GNU Make.  You can easily tell
by looking at them since they use make functions like call, etc. all
over the place, plus pattern rules and all sorts of fancy things :).

If you don't already have GNU Make, you would use one of the other
methods (like build_w32.bat) to create one.  Then after that you can
use these makefiles.

To remind: the purpose of these is to provide a makefile-based way to
_develop_ GNU Make itself, on platforms where we can't run ./configure
to get an automake-generated makefile.

If you need to build GNU Make from scratch there's not much benefit
from using Basic.mk, because it will just rebuild everything every time
just like the build_w32.bat etc. files.  You don't save anything.

But if you're doing ongoing development (edit/build/test cycle) and you
don't want to have to recompile all files every time you change
something, and you can't run ./configure, then you can use an already-
built GNU Make and these makefiles to shorten your development cycle.

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Costas Argyris]

No; those makefiles can only work with GNU Make.  You can easily tell
by looking at them since they use make functions like call, etc. all
over the place, plus pattern rules and all sorts of fancy things :).

I see - thanks for pointing that out (I don't have much experience with
Makefiles as you can probably tell).I guess that makes the task of
telling whether 'windres' is on the Windows path easier then, because
GNU Make extensions can be used in mk/Windows32.mk to do it.
I'll try and get something working and update the Basic.mk patch with
windres being optional, like in configure and build_w32.bat.

If you don't already have GNU Make, you would use one of the other
methods (like build_w32.bat) to create one.  Then after that you can
use these makefiles.

Indeed, it makes sense, thanks for the overall explanation.

On Wed, 17 May 2023 at 23:04, Paul Smith  wrote:

> On Wed, 2023-05-17 at 22:55 +0100, Costas Argyris wrote:
> > From a quick search there appear to be many ways
> > to do this, but some of them are GNU Make-specific,
> > and I believe these Makefiles (Basic.mk and those
> > included by it) have to work with any Make, not just
> > GNU Make.
>
> No; those makefiles can only work with GNU Make.  You can easily tell
> by looking at them since they use make functions like call, etc. all
> over the place, plus pattern rules and all sorts of fancy things :).
>
> If you don't already have GNU Make, you would use one of the other
> methods (like build_w32.bat) to create one.  Then after that you can
> use these makefiles.
>
> To remind: the purpose of these is to provide a makefile-based way to
> _develop_ GNU Make itself, on platforms where we can't run ./configure
> to get an automake-generated makefile.
>
> If you need to build GNU Make from scratch there's not much benefit
> from using Basic.mk, because it will just rebuild everything every time
> just like the build_w32.bat etc. files.  You don't save anything.
>
> But if you're doing ongoing development (edit/build/test cycle) and you
> don't want to have to recompile all files every time you change
> something, and you can't run ./configure, then you can use an already-
> built GNU Make and these makefiles to shorten your development cycle.
>

Re: [PATCH] Use UTF-8 active code page for Windows host.

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Wed, 17 May 2023 18:04:55 -0400
> 
> To remind: the purpose of these is to provide a makefile-based way to
> _develop_ GNU Make itself, on platforms where we can't run ./configure
> to get an automake-generated makefile.
> 
> If you need to build GNU Make from scratch there's not much benefit
> from using Basic.mk, because it will just rebuild everything every time
> just like the build_w32.bat etc. files.  You don't save anything.
> 
> But if you're doing ongoing development (edit/build/test cycle) and you
> don't want to have to recompile all files every time you change
> something, and you can't run ./configure, then you can use an already-
> built GNU Make and these makefiles to shorten your development cycle.

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.