On Sun, 2023-06-18 at 21:33 +0100, Costas Argyris wrote:
> Just checking to see if there is still interest in this feature.
I had that locally but hadn't had time to test it fully. Pushed now.
> From: Costas Argyris
> Date: Sun, 18 Jun 2023 21:33:03 +0100
> Cc: bug-make@gnu.org
>
> Just checking to see if there is still interest in this feature.
Nothing's changed, so yes.
Just checking to see if there is still interest in this feature.
On Thu, 18 May 2023 at 17:49, Costas Argyris
wrote:
> Please find attached the latest patch with everything done so far,
> including the inconsistency I mentioned in my previous email.
>
> This now has all 3 build approaches, namel
Please find attached the latest patch with everything done so far,
including the inconsistency I mentioned in my previous email.
This now has all 3 build approaches, namely:
1) configure
2) Basic.mk
3) build_w32.bat
treating the resource compiler optionally, and building and
embedding the UTF-8
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
> 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 G
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 c
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 makefil
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 searc
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
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
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 wor
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 starte
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 jus
> > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> > > I agree with the list. As for Basic.mk, we can forget about it
> > > from my POV. Paul should make the call, but from my POV that
> > > file was unmaintained and therefore unsupported.
> >
> > Why do we think it's unmaintained / un
On Sun, 2023-04-30 at 17:27 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > From: Paul Smith Date: Sun, 30 Apr 2023 09:55:55 -
> > 0400
> >
> > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> > > I agree with the list. As for Basic.mk, we can forget about it
> > > from my POV. Pa
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sun, 30 Apr 2023 09:55:55 -0400
>
> On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> > I agree with the list. As for Basic.mk, we can forget about it from
> > my POV. Paul should make the call, but from my POV that file was
> > unmainta
On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> I agree with the list. As for Basic.mk, we can forget about it from
> my POV. Paul should make the call, but from my POV that file was
> unmaintained and therefore unsupported.
Why do we think it's unmaintained / unsupported? It worked t
Hi
This is the latest patch based on the agreed remaining items:
> 1) Make build optional with respect to UTF-8:If windres is available,
> use it, if not, just build without UTF-8 support (current behavior).
> 2) Implement Paul's suggestion above to avoid having an empty target
> if HAVE_WIND
> From: Costas Argyris
> Date: Tue, 11 Apr 2023 14:50:53 +0100
> Cc: bug-make@gnu.org, psm...@gnu.org
>
> > AFAIK, GetACP can never return UTF-8, except if the program was
> > compiled with those resources.
>
> In the scenario I am describing, Make was compiled with the resource,
> so GetACP sho
AFAIK, GetACP can never return UTF-8, except if the program was
compiled with those resources.
In the scenario I am describing, Make was compiled with the resource,
so GetACP should return UTF-8 on the one hand.On the other hand
though, since Make is running in Windows version < 1903, it shoul
> From: Costas Argyris
> Date: Tue, 11 Apr 2023 14:42:30 +0100
> Cc: bug-make@gnu.org, Paul Smith
>
>> I don't think this is needed: if GetACP returns the UTF-8 codepage, it
>> must be that UTF-8 is supported. I'm not aware of any way of
>> affecting GetACP other than by a manifest such as this
I don't think this is needed: if GetACP returns the UTF-8 codepage, it
must be that UTF-8 is supported. I'm not aware of any way of
affecting GetACP other than by a manifest such as this one (or perhaps
making UTF-8 a system-wide default, which is fine by us).
This is the scenario I am concerned
> From: Costas Argyris
> Date: Tue, 11 Apr 2023 12:01:20 +0100
> Cc: Eli Zaretskii , bug-make@gnu.org
>
> > Being able to know whether UTF-8 is supported or not is a valid
> > concern. How about adding this information to what "make --version"
> > shows?
>
> I agreed with that suggestion and pr
Thank you both for your input.
I think you should move the assignment of UTF8OBJ out of the if-
statement here, and only put the update of make_LDADD into the if-
statement. That should be sufficient to have make ignore that target,
if there's no WINDRES available.
I'll make that change, thanks.
On Fri, 2023-04-07 at 08:29 -0400, Paul Smith wrote:
> > Also, I'm still waiting for Paul to approve the changes to Posix
> > configury part of your patch.
>
> Sorry I will make every effort to get to it today.
The configure part looks OK to me. This change to Makefile.am seems
not quite correct
On Thu, 2023-04-06 at 22:32 +0300, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Thu, 6 Apr 2023 22:04:48 +0300
> > Cc: bug-make@gnu.org, Paul Smith
> >
> > Hi and sorry to bother you again.
> >
> > I haven't received any response so
> > I was wondering if there is still
> > interest
> From: Costas Argyris
> Date: Thu, 6 Apr 2023 22:04:48 +0300
> Cc: bug-make@gnu.org, Paul Smith
>
> Hi and sorry to bother you again.
>
> I haven't received any response so
> I was wondering if there is still
> interest in doing this.
It's on my todo, but I'm busy these days.
Also, I'm still
Hi and sorry to bother you again.
I haven't received any response so
I was wondering if there is still
interest in doing this.
On Tue, 28 Mar 2023, 17:43 Costas Argyris, wrote:
> Being able to know whether UTF-8 is supported or not is a valid
> concern. How about adding this information to wha
Being able to know whether UTF-8 is supported or not is a valid
concern. How about adding this information to what "make --version"
shows?
I think this is a great idea, despite the fact that I expect most
build environments to actually have a resource compiler (either
windres or the msvc one) and
> From: Costas Argyris
> Date: Mon, 27 Mar 2023 23:04:52 +0100
> Cc: bug-make@gnu.org
>
> > Should we fail here? Or should we build without UTF-8 support since we
> > don't have a resource compiler? I think that's what the configure
> > version does, right?
>
> You are right, that was an incon
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Mon, 27 Mar 2023 16:35:42 -0400
>
> +:FindWindres
> +:: Show the resource compiler version that we found
> +echo.
> +call %RC% --version
> +if not ERRORLEVEL 1 goto Build
> +echo No %RC% found.
> +exit 1
>
> Should we fail here? Or should we bui
Thanks for looking into this, and good to hear that you are feeling better!
I still can't get Basic.mk to work, so not much to say on that...
Should we fail here? Or should we build without UTF-8 support since we
don't have a resource compiler? I think that's what the configure
version does, ri
I apologize for being incommunicado: for the last week I've been
fighting the mother of all head colds. The only good thing I can say
about it is that it was not COVID.
I'm sort of back on my feet.
On Sat, 2023-03-25 at 23:12 +, Costas Argyris wrote:
> and then from README.W32 -> Building w
Here is the new patch that includes the changes in build_w32.bat
required to build GNU Make with UTF-8 on Windows.
I have tested it with all 3 supported toolchains:
.\build_w32.bat (uses MSVC)
.\build_w32.bat gcc
.\build_w32.bat tcc
with/without --debug and with/without --x86 for MSVC.
> From: Costas Argyris
> Date: Sat, 25 Mar 2023 13:19:00 +
> Cc: psm...@gnu.org, bug-make@gnu.org
>
> > Also, I'd name the files slightly differently, something like
> > w32-utf8.*, to make their relation to Windows more evident.
>
> Note that in the patch, these files are put under the w32
Just some comments on the non-configury questions:
Also, I'd name the files slightly differently, something like
w32-utf8.*, to make their relation to Windows more evident.
Note that in the patch, these files are put under the w32 dir:
src/w32/utf8.manifest
src/w32/utf8.rc
so their relation to
> From: Costas Argyris
> Date: Tue, 21 Mar 2023 15:08:52 +
> Cc: bug-make@gnu.org, Paul Smith
>
> > You can submit diffs against the last released version here as well.
>
> In that case, I am simply re-attaching the patch I originally sent in
> this thread, because that was already develope
Yes I eventually found out about the maintainer mode by searching
for where -Werror is coming from, that's how I ended up using the
tarball (because there is no maintainer mode there).
Didn't know about README.git though - this does have a lot of info
indeed, thanks!
On Tue, 21 Mar 2023 at 17:24,
On Tue, 2023-03-21 at 12:52 +, Costas Argyris wrote:
> When trying from git, which was my first attempt, I was getting
> compilation warnings which were turning themselves into errors,
> so I never managed to build.
>
> When I used the sources extracted from the tarball though, this
> simply w
On Tue, 21 Mar 2023 15:08:52 +
Costas Argyris wrote:
> I am simply re-attaching the patch I originally sent in
> this thread, because that was already developed and built on 4.4.1
> tarball which is still the latest AFAICT.
Yes, at the time of this writing version 4.4.1 is the latest release
You can submit diffs against the last released version here as well.
In that case, I am simply re-attaching the patch I originally sent in
this thread, because that was already developed and built on 4.4.1
tarball which is still the latest AFAICT.
Just reminding that these changes are in Makefile
> From: Costas Argyris
> Date: Tue, 21 Mar 2023 12:52:54 +
> Cc: bug-make@gnu.org, Paul Smith
>
> > If so, could you please post it again, rebased on the current Git
> > master?
>
> There is an issue here:I noticed that when I was trying to build
> (cross-compile) Make for Windows using
If so, could you please post it again, rebased on the current Git
master?
There is an issue here:I noticed that when I was trying to build
(cross-compile) Make for Windows using a gcc + mingw-w64
cross-compiler (using Autotools, not build_w32.bat), there was a
big difference depending on wheth
> From: Costas Argyris
> Date: Mon, 20 Mar 2023 21:47:27 +
> Cc: bug-make@gnu.org, Paul Smith
>
> Any thoughts for next steps then?
If the patch ready to be installed?
If so, could you please post it again, rebased on the current Git
master?
And would you please consider working on changi
We won't know, not unless and until some user complains and debugging
shows this is the cause. But we can warn about this issue in the
documentation up front, so that people don't raise their expectations
too high.
Makes sense.
Any thoughts for next steps then?
On Mon, 20 Mar 2023 at 16:17, Eli
> From: Costas Argyris
> Date: Mon, 20 Mar 2023 14:58:39 +
> Cc: bug-make@gnu.org, Paul Smith
>
> Still my concern would be: assuming that we actually learn something
> from this test, how would we know:
>
> 1) Which other functions besides stricmp are affected?Maybe
> letter-case is no
It's not easy, AFAICS in the Make sources. Maybe it will be easier to
write a simple test program prepare a manifest for it, and see if
stricmp compares equal strings with different letter-case when
characters outside of the locale are involved.
I can do that.
Still my concern would be: assuming
Also, you didn't try to set the locale to .UTF-8, which is what that
page was describing.
That is because I am linking Make against MSVCRT, and that call
is only possible when linking against UCRT, AFAICT, so I didn't see
a reason to try.
CRT functions are implemented on top of Win32 APIs, and I
> From: Costas Argyris
> Date: Mon, 20 Mar 2023 13:45:14 +
> Cc: bug-make@gnu.org, Paul Smith
>
> > That's most probably because $(wildcard) calls a Win32 API that is
> > case-insensitive. So the jury is still out on this matter, and I
> > still believe that the below is true:
>
> In that
That's most probably because $(wildcard) calls a Win32 API that is
case-insensitive. So the jury is still out on this matter, and I
still believe that the below is true:
In that case, are you aware of any Make construct other than $(wildcard)
that will lead to calling an API of interest?I'd b
> From: Costas Argyris
> Date: Sun, 19 Mar 2023 21:25:30 +
> Cc: bug-make@gnu.org, Paul Smith
>
> I create a file src.β first:
>
> touch src.β
>
> and then run the following UTF-8 encoded Makefile:
>
> hello :
> @gcc ©\src.c -o ©\src.exe
>
> ifneq ("$(wildcard src.β)","")
> @echo src.β e
That's not a good experiment, IMO: the only non-ASCII character here
is U+274E, which has no case variants. And the characters whose
letter-case you tried to change are all ASCII, so their case
conversions are unaffected by the locale.
OK I think this is a better one, it is using U+03B2 and U+039
> From: Costas Argyris
> Date: Sun, 19 Mar 2023 16:34:54 +
> Cc: bug-make@gnu.org, psm...@gnu.org
>
> > OK, but how is the make.exe you produced built?
>
> I actually did what you suggested but was somewhat confused with the
> result.Usually I do this with 'ldd', but both msvcrt.dll and
OK, but how is the make.exe you produced built?
I actually did what you suggested but was somewhat confused with the
result.Usually I do this with 'ldd', but both msvcrt.dll and
ucrtbase.dll
show up in 'ldd make.exe' output, and I wasn't sure what to think of it.
However, your approach with o
> Date: Sun, 19 Mar 2023 16:38:08 +0200
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > From: Costas Argyris
> > Date: Sun, 19 Mar 2023 13:42:52 +
> > Cc: bug-make@gnu.org
> >
> > Also, since the above experiments seem to suggest that we are not
> > dropping existing support for non-ASCI
On Sun, 2023-03-19 at 16:47 +0200, Eli Zaretskii wrote:
> If we add tests for this feature (and I agree it's desirable), we
> should generate the files with non-ASCII names for those tests as
> part of the test script, not having them ready in the repository and
> the tarball.
Agreed for sure; plu
> From: Paul Smith
> Date: Sun, 19 Mar 2023 10:32:36 -0400
>
> It would be nice if there was a regression test or two created that
> would show this behavior.
If we add tests for this feature (and I agree it's desirable), we
should generate the files with non-ASCII names for those tests as part
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sun, 19 Mar 2023 10:27:16 -0400
>
> Other people (like Eli who is the primary maintainer of GNU Make for
> Windows) have other environments and do more vigorous testing. But I
> don't believe Eli uses autotools on Windows, either.
I do use autot
> From: Costas Argyris
> Date: Sun, 19 Mar 2023 13:42:52 +
> Cc: bug-make@gnu.org
>
> Does this support require Make to be linked against the UCRT
> run-time library, or does it also work with the older MSVCRT?
>
> I haven't found anything explicitly mentioned about this in the official
> do
On Sat, 2023-03-18 at 16:37 +, Costas Argyris wrote:
> The attached patch incorporates the UTF-8 manifest into the build
> process of GNU Make when hosted on Windows, and forces the
> built executable to use UTF-8 as its active code page, solving all
> problems shown above because this has a gl
On Sun, 2023-03-19 at 13:42 +, Costas Argyris wrote:
> I cross-compiled Make for Windows using gcc (mingw-w64) and the
> autoconf + automake + configure + make approach, so it clearly worked
> for me, but I didn't imagine that this wasn't the standard way to
> build for Windows host.
There is
Does this support require Make to be linked against the UCRT
run-time library, or does it also work with the older MSVCRT?
I haven't found anything explicitly mentioned about this in the official
doc:
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
Also, it i
> From: Costas Argyris
> Date: Sat, 18 Mar 2023 16:37:20 +
>
> This is a proposed patch to enable UTF-8 support in GNU Make running on
> Windows host.
Thanks.
> Today, the make process on Windows is using the legacy system code page
> because of the "A" functions
> called in the source co
64 matches
Mail list logo
