[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

[Eli Zaretskii]

Follow-up Comment #2, bug #66381 (group make):

The proposed patch will not work well on MS-Windows: it assumes that '/' is
the only possible directory separator character, and it ignores the
possibility of a drive letter in file names.

I hope these non-portable aspects will be fixed before this enhancement is
accepted.



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

Re: fixes for unlikely pointer overflow, buffer truncation

[Eli Zaretskii]

> From: Martin Dorey 
> CC: "bug-make@gnu.org" 
> Date: Mon, 5 Aug 2024 23:13:47 +
> 
> "Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no 
> longer identical to _snprintf. The snprintf behavior is now C99 standard 
> conformant. The difference is that if you run out of buffer, snprintf 
> null-terminates the end of the buffer and returns the number of characters 
> that would have been required whereas _snprintf doesn't null-terminate the 
> buffer and returns -1. Also, snprintf() includes one more character in the 
> output because it doesn't null-terminate the buffer."

This is only relevant to a build using MSVC, the Microsoft compiler.
(Yes, GNU Make does support it.)  If, OTOH, you use the MinGW tools,
then an ANSI-compatible implementation of snprintf is available there
(as part of an auxiliary library that is always submitted to the
linker) for much longer, and is the default for a very long time.

[bug #65777] add const misc global RO arrays

[Eli Zaretskii]

Update of bug #65777 (group make):

Severity:  3 - Normal => 1 - Wish   
 Assigned to:None => psmith 
   Component Version:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

Thanks.

These are basically cleanups.  I'm not sure we should make significant changes
in complicated code just to improve memory efficiency by a tiny bit.  I'll let
Paul make the decision, but my tendency is not to install these patches.



___

Reply to this item at:

  

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

[bug #65776] [PATCH 1/3] win32 STAT_LITE

[Eli Zaretskii]

Follow-up Comment #1, bug #65776 (group make):

We don't use GetFileAttributesEx because it doesn't exist on old Windows
systems, and GNU Make still wants to support those old systems.

So I don't think we should make these changes, sorrty.



___

Reply to this item at:

  

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

[bug #65775] [PATCH 2/2] win32 dir.c eliminate OS specific dir-cache agressive reread vs posix

[Eli Zaretskii]

Update of bug #65775 (group make):

 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #1:

Please elaborate on the need for these changes.  What are the advantages of
installing these two patches wrt the current code?  Is the current code wrong?
 Is it slower than the code after your changes?  Something else?

Again, this code is old and stable, so changing it needs a good reason, IMO.

Thanks.



___

Reply to this item at:

  

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

[bug #65774] [PATCH] win32: use link time optimization for Visual C Release build

[Eli Zaretskii]

Update of bug #65774 (group make):

Severity:  3 - Normal => 2 - Minor  
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

I have no objections to installing this patch, subject to copyright assignment
paperwork.

Thanks.



___

Reply to this item at:

  

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

[bug #65773] [PATCH] win32: on VC always make PDB debugging symbols for Release

[Eli Zaretskii]

Update of bug #65773 (group make):

Severity:  3 - Normal => 2 - Minor  
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

This patch is fine by me, but I believe we will need a copyright assignment
for you to accept this and other patches you sent.

Would you like me to send you the form to fill and the instructions to go with
it, so you could start your assignment paperwork rolling?



___

Reply to this item at:

  

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

[bug #65772] [PATCH] win32: don't twice search disk for $(SHELL) unless PATH or SHELL changed

[Eli Zaretskii]

Update of bug #65772 (group make):

Severity:  3 - Normal => 1 - Wish   
  Status:None => Wont Fix   
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Thanks, but no thanks.  This part of GNU Make is very old and it is stable. 
It is also tricky, as the issue of the value of SHELL in GNU Make on
MS-Windows is complicated.  I'm not interested in potentially destabilizing it
for the benefit of a couple of milliseconds.



___

Reply to this item at:

  

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

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

[Eli Zaretskii]

Update of bug #65771 (group make):

Severity:  3 - Normal => 2 - Minor  
  Item Group: Enhancement => Build/Install  
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Thanks.  Some comments to the proposed patch:

@@ -576,8 +578,8 @@ char *ttyname (int);
 
 /* Define {u,}intmax_t if not defined in  or . */
 #if !HAVE_STDINT_H && !HAVE_INTTYPES_H
-#define intmax_t long long
-#define uintmax_t unsigned long long
+#define intmax_t __int64
+#define uintmax_t unsigned __int64
 #endif

IMO, these changes should not be unconditional, but conditioned by _MSC_VER. 
It makes little sense to use __int64 in a GCC build.

--- a/src/dir.c
+++ b/src/dir.c
@@ -1106,7 +1106,7 @@ print_dir_data_base (void)
 #if MK_OS_W32
 printf (_("# %s (key %s, mtime %s): could not be opened.\n"),
 dir->name, dir->contents->path_key,
-make_ulltoa ((unsigned long long)dir->contents->mtime,
buf));
+make_ulltoa ((unsigned _quad_t)dir->contents->mtime,
buf));

Sane here.  And I don't understand why you use the _quad_t type here; at the
very least you should use unsigned __int64, no?  Similar comments to other
uses of _quad_t.

The definition of _quad_t that you suggest in makeint.h is perhaps okay, but
then (a) please don't use lower-case symbold that begins with an underscore,
as that is generally reserved, and (b) why have both intmax_t/uintmax_t and
_quad_t?

--- a/src/job.c
+++ b/src/job.c
@@ -22,6 +22,7 @@ this program.  If not, see . 
*/
 /* Default shell to use.  */
 #if MK_OS_W32
 # include 
+# include  /* for WSABASEERR */

I don't understand the need for this.  The following MS documentation page:

  
https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2

says that these errors are also declared in winerror.h, which windows.h
includes.  So why did you need an explicit inclusion on winsock2.h?

+#if (defined(_MSC_VER) && (_MSC_VER < 1900))
+//must use shim on all < VC 2015 s
+//
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
+#define snprintf _snprintf_c99

First, please don't use C++-style "//" comments.
And second, why was this needed? (I've read the page which you quote, and I
still don't think I understand the need, please explain.)

-# include /* for intptr_t */
+# include /* for INT_PTR */

Is INT_PTR indeed defined in stddef.h?  I very much doubt that.

 osync_parse_mutex (const char *mutex)
 {
   char *endp;
-  unsigned long long i;
+  UINT_PTR i;
 
   errno = 0;
+#if defined _WIN64
   i = strtoull (mutex, &endp, 16);
+#else
+  i = strtoul (mutex, &endp, 16);
+#endif

Why this change?  It adds an ugly #ifdef for no good reason.  Why not handle
the mutex as unsigned long long (a 64-bit type) in both 32-bit and 64-bit
builds?

+/*VC 6 doesn't have strtoi64, VC 7/2003 does */
+#if defined(_MSC_VER) && (_MSC_VER < 1300)
+/*  from ReactOS /sdk/lib/crt/string/strtoi64.c
+https://git.reactos.org/?p=reactos.git;a=blob;f=COPYING3;hb=HEAD
+*/
+/* Based on Wine Staging 1.9.9 - dlls/msvcrt/string.c */

If this code is indeed from Wine, I'm not sure we can accept it without them
assigning the copyright to us.  That's Paul's decision, obviously, but AFAIK
those are the rules of the GNU project regarding non-trivial contributions of
code.




___

Reply to this item at:

  

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

Re: [PATCH] src/main.c: Add -J to detect number of job slots based on nproc.

[Eli Zaretskii]

> Date: Fri, 12 Apr 2024 07:58:28 +0200
> From: Henrik Carlqvist 
> Cc: bug-make@gnu.org, matt.stav.tay...@gmail.com
> 
> On Fri, 12 Apr 2024 02:13:36 +0100
> Matt Staveley-Taylor  wrote:
> > Browsing the mailing list I can see that the behaviour of -j with no
> > arguments has been discussed a few times. Given it would affect
> > backwards compatability to change how -j works, introducing a new
> > flag seems appropriate.
> 
> Yes, it has been discussed. I would not mind if the default without argument
> for -j would be to limit to nproc or nproc+1, instead of like now, creating a
> fork bomb when compiling a big project.

Isn't nproc or nproc+1 too much?  On systems with hyper-threading,
this will try using too many jobs, and might cause the system be
significantly less responsive.  Maybe nproc/2 is a better default?

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #34, bug#64806 (group make):

That weird problem is with a particular build of Windows port of GNU Make, and
it is not clear to me on what OS the error was seem.

But yes, it sounds like it's a separate issue.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #32, bug#64806 (group make):

I don't think I understand what you mean by "change management aspect", and
why the behavior discussed here doesn't have much to do with the original
problem report.  Please elaborate.



___

Reply to this item at:

  

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

[bug #65273] Potential bug in the info function?

[Eli Zaretskii]

Follow-up Comment #5, bug#65273 (group make):

FWIW, I think it is very unfortunate that GNU Make started warning about this
trick, especially if there is no reasonable way of getting the same effect by
other means.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #30, bug#64806 (group make):

Thanks for the footwork and detailed information.
This is for Paul to decide, eventually, but I personally would prefer a
simpler way of calling osync_clear on MS-Windows only in the top-level Make. 
AFAIU, this should solve the problem without rocking the boat too much,
because other than this tricky issue, the current implementation was working
well for several releases, whereas changing it to use named mutexes that are
not inherited could easily uncover exciting new problems.

I understand that doing what I propose will make the Posix and MS-Windows
implementation different in one more way, but I don't see much harm in that,
since they are already quite different.  Documenting these aspects clearly
should go a long way towards mitigating this downside.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #28, bug#64806 (group make):

Thanks, this is important information.

So I think the next step is to understand which call to osync_clear closes the
handle.  Maybe we shouldn't make that call, at least on Windows?

Also, this only happens sometimes, right?  That is, -Otarget sometimes does
work, right?  So it isn't that inheriting mutex handles doesn't work in
general, it's more like sometimes the handle is "taken" after the child
process called osync_clear (which frees the handle for opening any other file
object), and then the handle is no longer usable as a mutex, and a grandchild
process inherits that unusable handle.

So perhaps only the top-level make, the one which calls CreateMutex, should
call CloseHandle on the mutex?  Can you try that?




___

Reply to this item at:

  

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

Re: Segmentation Fault on Exported Resursively Expanded Variable

[Eli Zaretskii]

> Date: Tue, 16 Jan 2024 19:21:04 +0100
> From: Henrik Carlqvist 
> Cc: psm...@gnu.org, bug-make@gnu.org
> 
> On Tue, 16 Jan 2024 06:59:30 +
> MIAOW Miao  wrote:
> > if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
> 
> Looking at that line, the rather obvious fix would be to change it to:
> 
> if (strncmp (*ep, v->name, nl) == 0 && (*ep)[nl] == '=')
> 
> That way, *ep can be no shorter than having \0 at position nl and accessing
> that position should not cause any segfault.

But it's less efficient when the (*ep)[nl] == '=' test fails.

Re: [bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

> Date: Mon, 15 Jan 2024 12:37:42 -0500
> From: Ken Brown 
> 
> This is a long shot, but I had a problem a year ago with parallel make 
> on Cygwin occasionally hanging.  The solution turned out to be to force 
> make's jobserver to use pipes instead of fifos.  If you want to try 
> this, pass make the option '--jobserver-style=pipe'.

Thanks.  But the native Windows port of GNU Make uses neither fifos
nor pipes for the jobserver implementation.  It uses Windows
semaphores.  Moreover, this problem is not with the jobserver, it is
with output-sync feature, which uses Windows mutexes to synchronize
output from separate subprocesses that produce different targets.

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #25, bug#64806 (group make):

The \Device\ConDrv thing is strange, not sure what to make of that. The one
process where the handle is shown as "Mutant" is correct, AFAIU.  Maybe it
means the child processes actually released the mutex, but then why does the
parent keep waiting, and why the children don't exit?

Otherwise, this looks like all of the child processes wait for the mutex
handle, and no process releases it.  What happens if you kill one of the
subprocesses -- do the rest continue being hung, or does the job resume
running?

Another idea is to build Make with additional printf's in osync_acquire and
osync_release to stderr, and see what the output tells us.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #23, bug#64806 (group make):

Do any other processes of those involved in the hang have this same mutex
handle open?



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #21, bug#64806 (group make):

Can you use ProcessExplorer (or some other SysInternals tool) to find out
which process, if any holds the handle that is the value of osync_handle, the
handle for which osync_acquire is waiting in the instances that are hung?



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #19, bug#64806 (group make):

When the stuff hangs, can you use ProcessExplorer to see which mutexes are
actually used by these Make processes, and how many of them are used?  You can
find the code which manipulates the mutexes in src/w32/w32os.c (look for the
osync_* functions near the end of the file).

maybe if we know which mutexes are used, that will help us understand what's
going on that causes the hang.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #18, bug#64806 (group make):

Very strange.  Looks like the parent process is waiting for the child to
finish, and the child process cannot acquire the mutex and also waits.

Are all of the 8 sub-make's in the same situation?

FWIW, I tried to run the Makefile you sent on my system, using my own MinGW32
build of Make 4.4.1, available here:

 https://sourceforge.net/projects/ezwinports/files/

and I cannot reproduce the hang, although I do see the "Cannot acquire output
lock, disabling output sync" warnings a couple of times during the run.  This
is with GCC 9.2.0 on Windows XP, FTR. Perhaps also relevant: on my system cmp0
to cmp7 jobs run together (in parallel), whereas cmp8 and cmp9 run afterwards
(in parallel with each other, but sequentially after cmp0-cmp7).  Is this
expected, given that I have a Core i7 machine with 4 cores and
hyperthreading?




___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #16, bug#64806 (group make):

>From the backtrace of the hung process, it looks like we wait forever for a
mutex to be released, which means some child process that holds the mutex
exited.  But the mutex is never released.  Do you see any other related
sub-processes that are hung at that time? Since Make is run with "-j 8", there
could be up to 8 Make sub-processes running for which we are waiting in the
top-level Make.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #13, bug#64806 (group make):

It would be helpful to understand which code cause the "Error 130" message to
be displayed, so as to allow interpreting that error, which might give us some
hint about what's going on.  If 130 is a value obtained from GetLastError,
then its meaning sounds strange for what Make does (something about using a
wrong handle for an open disk partition?).

By the way, I doubt that mingw32-make.exe is a 32-bit program.  All MSYS2
ports are nowadays 64-bit programs, regardless of the fact that the program
says it was built for Windows32.  But that is not important.  Th real
difference between make for pc-msys and mingw32-make is that only the latter
uses the mutex for synchronization, the pc-msys port uses a method similar to
the one used on GNU/Linux.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #8, bug #64806 (project make):

Is the brechtsanders build a 32-bit executable or a 64-bit executable?  If
it's a 64-bit executable, maybe the problem only rears its ugly head in a
64-bit build, because the ezwinports stuff is 32-bit.



___

Reply to this item at:

  

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

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Update of bug #64806 (project make):

   Triage Status:None => Need Info  

___

Follow-up Comment #4:

This bug report lacks a reproduction recipe, preferably one that doesn't
require to download huge packages and trying to build them.

In addition, it is not clear whether the make.exe binary which exhibits the
problem is the one from ezwinports or something else, and if it is from
ezwinports, what package exactly was downloaded from ezwinports (there are 2
binary packages of GNU Make there).

So more information is needed to make any progress with this bug report.



___

Reply to this item at:

  

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

Re: GNU make troubleshooting

[Eli Zaretskii]

> From: Paul Smith 
> Cc: br...@clisp.org, bug-make@gnu.org
> Date: Sun, 27 Aug 2023 09:16:59 -0400
> 
> On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote:
> > This checklist is very useful, but to make it even more useful, it
> > lacks two things:
> > 
> >  . an example of error message that indicates each kind of problem
> >  . a cross-reference to where the details are
> 
> There is a menu of links to each type of error just below the list,
> because this is a chapter node in texinfo; like:

Yes, I know.  But a single @xref after each item in the "checklist"
will be a great help, IMO.

> > I would suggest to add here a short description of how to interpret
> > these exit codes.  The codes 2 and -1 are very frequent, so maybe
> > explain them right here.
> 
> What should we explain about them?

That error code 2 means file not found, and -1 means a command was not
found or completely failed to run.  It is easy to show a couple of
examples for each one, we see those every day.

> > Removing @ is not always enough.  Many makefiles nowadays need you to
> > say "make V=1" to override the default verbosity level.  I suggest to
> > mention that.
> 
> What does "V=1" do, that removing the "@" doesn't do?

It shows the full command instead of something like

  CC foo.o

> I'm not familiar with any makefile where "V=1" enables "extra"
> debugging: normally it just disables "@".  I would prefer to avoid
> adding descriptions that depend on how specific makefiles are
> implemented, unless that is also described in the GNU Make manual.

The V=1 stuff is nowadays standard in the GNU project's makefiles, so
I think it would be a good addition.  Of course, it's your call.

Re: GNU make troubleshooting

[Eli Zaretskii]

> From: Paul Smith 
> Date: Sat, 26 Aug 2023 12:48:05 -0400
> 
> I added a new appendix to the GNU make manual for troubleshooting help;
> I haven't pushed it yet.  See below.  Comments welcome.

Thanks, this sounds very useful.  Some comments below.

>If you have problems with GNU Make, first consider the type of
> problem you are having.  Problems will generally be in one of these
> categories:
> 
>* A syntax or other error was reported when 'make' attempted to parse
>  your makefiles.
> 
>* A command that 'make' invoked failed (exited with a non-0 exit
>  code).
> 
>* The command that 'make' invoked was not the one you expected.
> 
>* 'make' was not able to find a rule to build a target.
> 
>* 'make' rebuilds a target that you didn't think was out of date.
> 
>* Or, 'make' did not rebuild a target that you expected it to build.

This checklist is very useful, but to make it even more useful, it
lacks two things:

 . an example of error message that indicates each kind of problem
 . a cross-reference to where the details are

It is possible that just a cross-reference could be enough, since you
already have an example of an error message there, but I still suggest
to maybe include it here: the appendix is large, and describes very
different problems, so being able to quickly go to the relevant part
is invaluable IME.

> C.2 Errors Reported by Commands
> ===
> 
> If GNU Make parses the makefiles correctly and runs a command to rebuild
> a target, it expects that command to exit with an error code of '0' (for
> success).  Any other exit code will be reported by 'make' as a failure
> and will generate an error message with this form:
> 
>  make: *** [Makefile:10: target] Error 2
> 
>All the information you need to find that command are given: the name
> of the makefile (here 'Makefile') and line number (here '10') of the
> command make invoked, the target (here 'target') that make was trying to
> build, and finally the exit code of the command (here '2').

I would suggest to add here a short description of how to interpret
these exit codes.  The codes 2 and -1 are very frequent, so maybe
explain them right here.  For the other, I would tell the reader to
look in the documentation of the failed command.

>If the makefile doesn't provide a rule for this target, you can add
> one.  If there is a rule which you intended 'make' to use to build this
> target and it wasn't used, the most common reasons for this are:
> 
>* The target was misspelled.  You should consider following the _DRY_
>  principle (Don't Repeat Yourself) by assigning file names (targets
>  and prerequisites) to makefile variables and using those variables
>  rather than retyping the file names.
> 
>* The target is in a different directory.  'make' considers the
>  targets 'target' and 'dir/target' (for example) to be different
>  targets.  If you are using rules that create targets outside of the
>  current working directory, be sure you correctly prefix them with
>  their directories everywhere that they appear in the makefile.
> 
>* A pattern rule didn't match because one of its prerequisites cannot
>  be built.  Pattern rules will only be used when *all* prerequisites
>  can be satisfied: either they exist already or 'make' can find a
>  way to build them.  If any prerequisite cannot be created, then the
>  pattern does not match and 'make' will continue looking for another
>  matching pattern.  If no matching pattern can be found, then 'make'
>  will fail.

I would add one more item: a pattern rule has an error.  It might be
included in the first item above, but it is not obvious, and pattern
rules are sometimes tricky to write.

>To troubleshoot these issues (*note Strategies for Troubleshooting:
> Troubleshooting Strategies.), remove the '@' prefix in your recipe when
> 'make' does rebuild the target so you can see what command is being
> invoked.

Removing @ is not always enough.  Many makefiles nowadays need you to
say "make V=1" to override the default verbosity level.  I suggest to
mention that.

> Remove '@' prefixes
> ---
> 
> If your makefile is using the '@' prefix in recipes to prevent 'make'
> from echoing the commands it invokes (*note Recipe Echoing: Echoing.),
> the first thing you should do is remove this token so that you can see
> the full command line that 'make' is running.  This will help you
> understand what your recipe is actually doing.

And here.

Thanks!

Re: GNU make troubleshooting

[Eli Zaretskii]

> From: Bruno Haible 
> Date: Mon, 10 Jul 2023 21:41:24 +0200
> 
> Paul Smith wrote:
> > Showing the "macroexpanded make sources" is difficult because make
> > doesn't just expand an entire line then parse it.  Makefile syntax is
> > context-sensitive so you can't know how or if to expand parts of a line
> > until you've already expanded other parts.  Of course make could keep
> > track of this for generating this kind of output.
> 
> If no perfect solution to this problem is possible, how about
> implementing a simple approximation first, and then improve it based
> on user feedback?

An approximation to the facts is worse than the facts.

This facility is supposed to show you which files caused a target to
be rebuilt.  Any approximation that doesn't list all of those outdated
files will lose information.

The fact that you saw a long list is a bug that was solved.  Making
Make less capable because of a bug is not wise, IMO.

Re: GNU make troubleshooting

[Eli Zaretskii]

> From: Jeffrey Walton 
> Date: Mon, 10 Jul 2023 16:34:49 -0400
> Cc: bug-make@gnu.org
> 
> I would add GNU's make lacks minimal debug facilities.

I think "make -p" and "make -d" do provide ample debugging
capabilities.

> I think trace is worthless. It does not help the folks writing
> makefiles. Or it has never helped me understand why a statement was
> (or was not) evaluated, or the result of the evaluation.

Then you should be free not to use that option.  I personally think it
does help in some situations.

[bug #64339] $(filter) and $(filter-out) interpret "match" in surprising ways

[Eli Zaretskii]

URL:
  <https://savannah.gnu.org/bugs/?64339>

 Summary: $(filter) and $(filter-out) interpret "match" in
surprising ways
   Group: make
   Submitter: eliz
   Submitted: Thu 22 Jun 2023 10:07:13 PM IDT
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 22 Jun 2023 10:07:13 PM IDT By: Eli Zaretskii 
The GNU Make Manual says:

'$(filter-out PATTERN...,TEXT)'
 Returns all whitespace-separated words in TEXT that _do not_ match
 any of the PATTERN words, removing the words that _do_ match one or
 more.  This is the exact opposite of the 'filter' function.

 For example, given:

  objects=main1.o foo.o main2.o bar.o
  mains=main1.o main2.o

 the following generates a list which contains all the object files
 not in 'mains':

  $(filter-out $(mains),$(objects))

Note that the text doesn't really say what it means to "match" in this
context, nor what exactly is PATTERN. The example might make you believe the
"match" means "substring". That is A "matches" B if A is some substring of B.
But this is not the case. Observe:

$ make -f-
ORIG=foo123 bar-xyz baz-yes
EXCLUDE=bar foo
all:
@echo "$(filter-out $(EXCLUDE),$(ORIG))"
^D
=> foo123 bar-xyz baz-yes

That is, "foo123" does NOT match "foo", and "bar-xyz" does NOT match "bar".
The following does work, though:

$ make -f-
ORIG=./foo ./bar ./baz
EXCLUDE=%bar %foo
all:
@echo "$(filter-out $(EXCLUDE),$(ORIG))"
^D
=> ./baz

So now we perhaps understand that PATTERN is something that includes the %
wildcard somewhere. This should be explained in the manual, and the manual
should also somehow justify the special case of exact string equality, in
which case the % wildcard is not required.

IOW, having the exact string equality as the only example in this case is
misleading and confusing. I learned this the hard way, having just spent an
hour debugging my Makefile where $(filter-out) didn't do its job, because I
thought "./foo" should match "foo", based on what the manual says.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64339>

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

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

[Eli Zaretskii]

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

Re: Unable to cross build for Windows

[Eli Zaretskii]

> From: Martin Dorey 
> CC: "bug-make@gnu.org" 
> Date: Fri, 9 Jun 2023 06:32:28 +
> msip_labels:
> 
> #include 
> 
> intptr_t _get_osfhandle(int);
> typedef void* HANDLE;
> 
> HANDLE fn() {
>   return (HANDLE)_get_osfhandle(0);
> }
> martind@sirius:~/tmp/svensson-2023-06-08$ gcc -c -Wbad-function-cast make.c
> make.c: In function ‘fn’:
> make.c:7:10: warning: cast from function call of type ‘intptr_t {aka long 
> int}’ to non-matching type ‘void *’ [-Wbad-function-cast]
>    return (HANDLE)_get_osfhandle(0);
>           ^
> martind@sirius:~/tmp/svensson-2023-06-08$ 
> 
> That's gcc-6.3, but it's much the same in every version I tested from gcc-4.4 
> to gcc-10.  A random version's man page, 
> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Warning-Options.html, explains 
> the flag as to:
> 
> > Warn when a function call is cast to a non-matching type. For example, warn 
> > if a call to a function returning an integer type is cast to a pointer type.
> 
> I fear they mean exactly what they say there.  So, while you might call it a 
> mistake, I don't think it's an accident.  
> https://stackoverflow.com/a/35308713/18096 has some explanation of why it 
> might sometimes be useful... and how it could be sidestepped by a change to 
> Gnu Make, like our new friend wished for.

Yes, it sounds like -Wbad-function-cast will always emit a warning in
such cases, and one cannot use it with the likes of _get_osfhandle,
which _require_ such casts.

You can, of course, work around it; the following compiles without a
warning:

#include 

intptr_t _get_osfhandle(int);
typedef void* HANDLE;

HANDLE fn() {
  intptr_t handle = _get_osfhandle(0);
  return (HANDLE)handle;
}

Re: Unable to cross build for Windows

[Eli Zaretskii]

> Date: Thu, 8 Jun 2023 20:39:43 +0200
> CC: 
> From: Torbjorn SVENSSON 
> 
> > If you get the error about casting _get_osfhandle to HANDLE only for
> > the 32-bit build, and you don't care about that build, then just
> > ignore it.  But if that error is emitted for the 64-bit build, then
> > there's something strange here, since on 64-bit Windows 'long long'
> > should be compatible with 'void *'.
> 
> The error is emitted in both builds, but let's ignore 32-bit for now.
> Both the errors that I pasted above are emitted using
> x86_64-w64-mingw32 and need to have some kind of fix to have a successful
> build.
> 
> Any idea what could be done except disabling the warning for the cast.

I'd post to the MinGW64 forum and perhaps also to the GCC list.  It
sounds like a bogus warning to me, i.e. a bug.  The question is: is
the bug in GCC itself or in some MinGW64 header files?

Re: Unable to cross build for Windows

[Eli Zaretskii]

> Date: Thu, 8 Jun 2023 16:19:04 +0200
> CC: 
> From: Torbjorn SVENSSON 
> 
> On 2023-06-08 16:14, Eli Zaretskii wrote:
> >> Date: Thu, 8 Jun 2023 14:44:35 +0200
> >> From: Torbjorn SVENSSON 
> >>
> >> /build/gnu-make_4.4.1-45-g07fcee35/src/function.c: In function 
> >> 'windows32_openpipe':
> >> /build/gnu-make_4.4.1-45-g07fcee35/src/function.c:1676:12: error: cast 
> >> from function call of type 'intptr_t {aka long long int}' to non-matching 
> >> type 'void *' [-Werror=bad-function-cast]
> >>  tmpErr = (HANDLE)_get_osfhandle (errfd);
> >>   ^
> >>
> >>
> >> /build/gnu-make_4.4.1-45-g07fcee35/src/job.c: In function 
> >> 'create_batch_file':
> >> /build/gnu-make_4.4.1-45-g07fcee35/src/job.c:365:3: error: format not a 
> >> string literal and no format arguments [-Werror=format-security]
> >>  O (fatal, NILF, error_string);
> >>  ^
> >>
> >>
> >> On the MSDN page for _get_osfhandle, they recommend to case the return 
> >> value
> >> to HANDLE, but GCC apparently thinks this is not allowed.
> >> Any idea on how to get around this issue?
> >>
> >>
> >> For the O()-macro; is it correct to use the macro with a variable?
> >> Maybe it's more appropriate to fall fatal directly with the arguments?
> > 
> > Is this with x86_64 being the target or i686?  I'm guessing the
> > latter, since for 64-bit Windows 'long long' and 'void *' are of the
> > same width.  If it's indeed for i686, are you sure the MinGW64 headers
> > you have support 32-bit builds?  Because AFAIR MinGW64 tossed
> > supported for old Windows versions, which basically means they don't
> > support 32-bit Windows.
> 
> The idea is to have a 64-bit make application. I just included the i686
> log for completeness.

If you get the error about casting _get_osfhandle to HANDLE only for
the 32-bit build, and you don't care about that build, then just
ignore it.  But if that error is emitted for the 64-bit build, then
there's something strange here, since on 64-bit Windows 'long long'
should be compatible with 'void *'.

Re: Unable to cross build for Windows

[Eli Zaretskii]

> Date: Thu, 8 Jun 2023 14:44:35 +0200
> From: Torbjorn SVENSSON 
> 
> /build/gnu-make_4.4.1-45-g07fcee35/src/function.c: In function 
> 'windows32_openpipe':
> /build/gnu-make_4.4.1-45-g07fcee35/src/function.c:1676:12: error: cast from 
> function call of type 'intptr_t {aka long long int}' to non-matching type 
> 'void *' [-Werror=bad-function-cast]
> tmpErr = (HANDLE)_get_osfhandle (errfd);
>  ^
> 
> 
> /build/gnu-make_4.4.1-45-g07fcee35/src/job.c: In function 'create_batch_file':
> /build/gnu-make_4.4.1-45-g07fcee35/src/job.c:365:3: error: format not a 
> string literal and no format arguments [-Werror=format-security]
> O (fatal, NILF, error_string);
> ^
> 
> 
> On the MSDN page for _get_osfhandle, they recommend to case the return value
> to HANDLE, but GCC apparently thinks this is not allowed.
> Any idea on how to get around this issue?
> 
> 
> For the O()-macro; is it correct to use the macro with a variable?
> Maybe it's more appropriate to fall fatal directly with the arguments?

Is this with x86_64 being the target or i686?  I'm guessing the
latter, since for 64-bit Windows 'long long' and 'void *' are of the
same width.  If it's indeed for i686, are you sure the MinGW64 headers
you have support 32-bit builds?  Because AFAIR MinGW64 tossed
supported for old Windows versions, which basically means they don't
support 32-bit Windows.

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.

Re: New feature request: custom Makefile location

[Eli Zaretskii]

> Date: Fri, 5 May 2023 12:47:35 +0300
> From: Nagy Ákos 
> 
> I want to configure a custom location for a Makefile.
> 
> I use the make tool as sysadmin, and I use the same makefile for each 
> usualy docker project, and I need to copy it to all folders where I use 
> it, and I need to update it on all location.
> 
> 
> Workflow:
> 
> automatic detection: when the make tool don't found the makefile in 
> local folder, can check an environment variable (ex: MAKEFILE_LOCATION) 
> and if exist, can use it
> 
> manual flag: can add a new configuration flag to make: make 
> --location=/home/user/

How is this different from saying

  $ make -f /path/to/location/Makefile

?

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

[Eli Zaretskii]

> 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
> > unmaintained and therefore unsupported.
> 
> Why do we think it's unmaintained / unsupported?

Because I never use it when building the MinGW port of Make.

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

[Eli Zaretskii]

> 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 should return UTF-8 on the one hand.On the other hand
> though, since Make is running in Windows version < 1903, it shouldn't
> return UTF-8 because this functionality is not supported in that version.

That is what will happen, AFAIK.

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

[Eli Zaretskii]

> 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 one (or perhaps
>> making UTF-8 a system-wide default, which is fine by us).
> 
> This is the scenario I am concerned about:
> 
> Assume Make was built with UTF-8 support, and downloaded by a
> user running Windows < 1903.I am not sure what GetACP would
> return in this case - If it returns the legacy code page, despite the
> fact that the UTF-8 manifest is embedded in Make, then we are good.
> But if GetACP returns UTF-8, because of the manifest that was
> embedded at build time, this will be confusing because --version will
> say UTF-8 but Make will actually work in the legacy encoding because
> of the < 1903 Windows version.

AFAIK, GetACP can never return UTF-8, except if the program was
compiled with those resources.

> I haven't tested this though, so it might not even be a real issue, just
> noting it down to check it later when I have the implementation.

Yes, verifying this would be good, thanks.

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

[Eli Zaretskii]

> 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 proposed a plan, but didn't receive
> final confirmation on it.
> 
> As far as I can tell, the only scenario where GNU Make is not built
> with UTF-8 is if it gets built with tcc, which doesn't have a resource
> compiler.Both gcc and msvc have resource compilers (gcc through
> binutils which gcc depends on anyway).But since tcc is a supported
> compiler as well, and we don't want to break it for the sake of UTF-8,
> then we must provide users with a way to tell if Make was built with
> UTF-8 support or not.
> 
> I think outputting this info can be as simple as adding a call to GetACP
> in some appropriate place in the source code.

Yes, I think so.

> Note that this is going
> to be a windows-specific call.If you can point me at some candidate
> locations in the source code for adding that call, it would greatly speed
> things up.Otherwise I would just try to find where the --version output
> is computed and try and add a windows-specific branch somewhere
> there.

I think Windows-specific code in print_version (in main.c) should be
fine, but perhaps just call a function there, and the function itself
should be in a Windows-specific file, like w32/w32os.c.

> There is one more complication about this: As we have stated before,
> this work only has a positive effect on Windows Version 1903 or later.
> Earlier versions will still work, but won't get UTF-8.So would it make
> any sense if we reported UTF-8 in --version for versions of Windows
> earlier than 1903?Perhaps the check should include both Windows
> version and GetACP - thoughts?

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

> To summarize, I think the list of things do be done is:
> 
> 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_WINDRES is not set.
> 3) Add active code page used in "make --version" output, for Windows.
> Potentially also check Windows version.
> 4) Can we officially forget about bringing the UTF-8 changes to Basic.mk?
> As I have said before, I haven't managed to build using these Makefiles.
> Actually, having the code page output by --version would greatly help with
> this as well - if one built GNU Make using Basic.mk, they wouldn't get
> UTF-8 support but this would still be readable in --version so no surprises.

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.

Thanks.

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

[Eli Zaretskii]

> 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 waiting for Paul to approve the changes to Posix
configury part of your patch.

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

[Eli Zaretskii]

> 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 inconsistency on my part, sorry about that.
> It's true that the configure version is optional on this, whereas
> build_w32.bat errors out.
> 
> I think the answer depends on what is going to be the policy regarding
> Make on Windows and UTF-8.If we want to claim that Make on Windows
> has gone UTF-8, matching fully the Unix-based platforms, then it has to
> be an error if it can't be built as such.My personal opinion is that this
> is the way forward, because it may be confusing if we end up in a
> situation where some users have a UTF-8 version of Make and some
> others don't.

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 just go full UTF-8 like the other systems.

But it isn't "full UTF-8", as we have established during the
discussions.  MS-Windows is not yet ready for that, even in its latest
versions.

> Of course, users on versions of Windows earlier than the target version
> that supports this feature still won't get UTF-8, but that would be because
> of their version of Windows, not because of the way Make was built.

Right.

> That is, I am more inclined to make the configure version also error
> out if windres was not found, than to make build_w32.bat optional.

I'm of the opposite opinion.

> This is mostly based on the fact that windres is part of binutils which is
> pretty much ubiquitous because gcc itself relies on its tools (most
> notably the assembler and linker).So if someone is building with
> gcc, they will almost certainly already have windres.For building
> with MSVC that's a non-issue because MSVC comes bundled with its
> own resource compiler, so it is always going to be there.

Then this is a non-issue: the error will not happen except in some
situations we cannot imagine.

> So I think it is reasonable to expect that there is always going to be a
> resource compiler available.Even if not, say, when building with tcc,
> it is always possible to error out with a message saying to install binutils.

I'd like to avoid annoying users with requests to install something
they did well without previously.  Some would consider this a
regression.

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

[Eli Zaretskii]

> 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 build without UTF-8 support since we
> don't have a resource compiler?  I think that's what the configure
> version does, right?  This is up to you and Eli, I can see both sides.

I think building without URF-8 support is better than a total failure,
yes.

Paul, what about the changes to the Posix configury?  I don't feel I'm
familiar enough with how building GNU Make uses that, so I'd like your
approval before I install that part of the patch, lest I somehow break
the other systems.

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

[Eli Zaretskii]

> 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 dir:
> 
> src/w32/utf8.manifest
> src/w32/utf8.rc
> 
> so their relation to Windows is already showing from that.

I'll leave that to Paul.

> 1) In build_w32.bat, there are 3 compilers supported:
> MSVC, gcc and tcc (Tiny C Compiler).I can see the changes
> working for MSVC and gcc, but what about tcc?
> 
> AFAICT, it has no resource compiler to compile the .rc file
> to an object file.It can link against the object file though,
> assuming that it was produced by windres in the first place:
> 
> https://github.com/TinyCC/tinycc/blob/mob/win32/tcc-win32.txt#L92
> 
> But if one has tcc on its own and no windres, it doesn't
> seem possible to do it, so we need to decide if we are
> still going to build but without UTF-8 support, or error
> out, or try to find windres for compiling the .rc file and
> still use tcc for the rest (kind of a mixed approach).

Either the TCC build will not support this feature, or installing the
manifest (at least in some cases) is not such a bad idea after all.

> 2) From README.W32, there is another way to build
> 
> Basic.mk
> 
> which sources mk/Windows32.mk when building for Windows.
> 
> mk/Windows32.mk has a TOOLCHAIN variable that can be
> either "msvc" or "gcc" (no tcc option here).
> 
> Should mk/Windows32.mk also be updated for UTF-8 for
> both toolchains?

I don't know what is the status of these *.mk files and whether we
want to keep supporting them.  I have never used them.  Paul?

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

[Eli Zaretskii]

> 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 developed and built on 4.4.1
> tarball which is still the latest AFAICT.
> 
> Just reminding that these changes are in Makefile.am and configure.ac
> so you would have to build using that approach to actually get a
> UTF-8 Make on Windows host.
> 
> The other two files of the patch, utf8.manifest and utf8.rc will be
> useful for the build_w32.bat approach as well because they will
> be reused by it (I don't see a reason why not).

OK.

Paul, I'd appreciate your review as well, as I'm less familiar with
the Posix configury of Make, and could easily miss some subtle issue.

Looking at the patch now, I have a few minor comments:

> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -46,6 +46,8 @@ w32_SRCS =  src/w32/pathstuff.c src/w32/w32os.c 
> src/w32/compat/dirent.c \
>   src/w32/subproc/misc.c src/w32/subproc/proc.h \
>   src/w32/subproc/sub_proc.c src/w32/subproc/w32err.c
>  
> +w32_utf8_SRCS = src/w32/utf8.rc src/w32/utf8.manifest
> +
>  vms_SRCS =   src/vms_exit.c src/vms_export_symbol.c src/vms_progname.c \
>   src/vmsdir.h src/vmsfunctions.c src/vmsify.c
>  
> @@ -90,6 +92,14 @@ else
>make_SOURCES += src/posixos.c
>  endif
>  
> +if HAVE_WINDRES
> +  UTF8OBJ = src/w32/utf8.$(OBJEXT)
> +  make_LDADD += $(UTF8OBJ)
> +endif
> +
> +$(UTF8OBJ) : $(w32_utf8_SRCS)
> + $(WINDRES) $< -o $@
> +
>  if USE_CUSTOMS
>make_SOURCES += src/remote-cstms.c
>  else
> diff --git a/configure.ac b/configure.ac
> index cd78575..8cbf986 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -444,6 +444,7 @@ AC_SUBST([MAKE_HOST])
>  
>  w32_target_env=no
>  AM_CONDITIONAL([WINDOWSENV], [false])
> +AM_CONDITIONAL([HAVE_WINDRES], [false])
>  
>  AS_CASE([$host],
>[*-*-mingw32],
> @@ -451,6 +452,10 @@ AS_CASE([$host],
>  w32_target_env=yes
>  AC_DEFINE([WINDOWS32], [1], [Build for the WINDOWS32 API.])
>  AC_DEFINE([HAVE_DOS_PATHS], [1], [Support DOS-style pathnames.])
> +# Windows host tools.
> +# If windres is available, make will use UTF-8.
> +AC_CHECK_TOOL([WINDRES], [windres], [:])
> +AM_CONDITIONAL([HAVE_WINDRES], [test "$WINDRES" != ':'])
>])
>  
>  AC_DEFINE_UNQUOTED([PATH_SEPARATOR_CHAR],['$PATH_SEPARATOR'],

I think instead of using "if HAVE_WINDRES" it would be better to have
UTF8OBJ to be computed by configure, leaving it empty on builds that
don't target Windows.  That's because AC_CHECK_TOOL test for 'windres'
might not be the bets future proof text: users could have that
installed for reasons unrelated to the build target.

If my suggestion is accepted, the make_LDADD addition will not be
needed; instead make_LDADD will always mention $(UTF8OBJ), and the
value will be empty when not building for Windows.

Also, I'd name the files slightly differently, something like
w32-utf8.*, to make their relation to Windows more evident.

Finally, would we want to install the manifest file together with the
executable, and if so, should its installation name be
make.exe.manifest?

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

[Eli Zaretskii]

> 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 a gcc + mingw-w64
> cross-compiler (using Autotools, not build_w32.bat), there was a
> big difference depending on whether I was using the Make source
> code from git or the tarball.
> 
> 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 wasn't the case so I was able to cross-compile just fine.
> 
> Then the problem was how to track my changes, since I don't
> have git any more.What I did just to get a patch posted was
> to simply 'git init' a repository in the extracted sources just so
> I could use 'git diff' and so forth.That way, I created the patch
> I originally posted.
> 
> The problem now is that in order to rebase on the current Git
> master, I'd have to use Git, so I'll fall back to the original problem
> of not being able to build because of the warnings being treated
> as errors.

If this gives you so much trouble, just post the diffs against the
last release's tarball, and I will take it from there.

> Is this a known issue?

I'm not aware of it, but then I don't cross-build Make, and rarely
build it from Git anyway.

> Or is it just that not many people are
> cross-compiling for Windows using gcc and autotools (i.e. not
> using build_w32.bat)?

Not sure.  I think the MSYS2 folks do use the configury, but they use
it on Windows, not on GNU/Linux (i.e., they build natively, not by
cross-compiling).

> That being said, I haven't tried to build the Git source code
> using build_w32.bat, so for all I know maybe that doesn't
> lead to the warnings/errors I got with autotools (mostly because
> that would be a native compile, as opposed to the cross-compile
> I am doing with autotools).

You can submit diffs against the last released version here as well.

> > And would you please consider working on changing build_w32.bat as
> > well?
> 
> Absolutely, I haven't forgotten about this.I haven't looked into
> that file at all though, so I don't know how it configures its Makefiles,
> how it detects the toolchain etc, so I may need some help to speed
> things up.But definitely planning to do so in the coming days, or
> weekend at worst.

Thanks.  Please don't hesitate to ask questions.

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

[Eli Zaretskii]

> 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 changing build_w32.bat as
well?

Thanks.

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

[Eli Zaretskii]

> 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 not the only problematic aspect.
> 2) Which of the above (#1) set of functions are actually called from
> Make source code, directly or indirectly?
> 3) Which of the above (#2) set of functions could be called with UTF-8
> input that would cause them to break?

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.

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

[Eli Zaretskii]

> 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 case, are you aware of any Make construct other than $(wildcard)
> that will lead to calling an API of interest?I'd be happy to test it 
> against
> the patched UTF-8 version of Make that I have built.

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.

> In any case, do you see this as a blocking issue for the UTF-8 feature?

Not a blocking issue, just something that we'd need to document, for
users to be aware of.

> Is the concern that the UTF-8 feature might break existing things that
> work, or that some things that we might naively expect to work with the
> switch to UTF-8, won't actually work?

I don't think this will break something that isn't already broken.
But it could trigger expectations that cannot be met, and so we should
document these caveats.

> > This is about UCRT specifically, so I wonder whether MSVCRT will
> > behave the same.
> 
> That's true.I wonder how the examples I did so far worked, given
> that (as you found out) my UTF-8-patched Make is linked against
> MSVCRT.Is it just that everything I tried so far is so simple that it
> doesn't even trigger calls to sensitive functions in MSVCRT?

I think so, yes.

Also, you didn't try to set the locale to .UTF-8, which is what that
page was describing.

> Because
> from what I found online, MSVCRT does not support UTF-8, and yet
> somehow things appear to be working, at least on the surface.

CRT functions are implemented on top of Win32 APIs, and I think the
manifest affects the latter.  That's why it works.  Functionality that
is implemented completely in CRT, such as setlocale, for example, does
indeed need UCRT to work.  Or at least this is my guess.

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

[Eli Zaretskii]

> 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.β exists
> else
> @echo src.β does NOT exist
> endif
> 
> ifneq ("$(wildcard src.Β)","")
> @echo src.Β exists
> else
> @echo src.Β does NOT exist
> endif
> 
> ifneq ("$(wildcard src.βΒ)","")
> @echo src.βΒ exists
> else
> @echo src.βΒ does NOT exist
> endif
> 
> and the output of Make is:
> 
> C:\Users\cargyris\temp>make -f utf8.mk
> src.β exists
> src.Β exists
> src.βΒ does NOT exist
> 
> which shows that it finds the one with the upper case extension as well,
> despite the fact that it exists in the file system as a lower case extension.

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:

> My guess would be that only characters within the locale, defined by
> the ANSI codepage, are supported by locale-aware functions in the C
> runtime.  That's because this is what happens even if you use "wide"
> Unicode APIs and/or functions like _wcsicmp that accept wchar_t
> characters: they all support only the characters of the current locale
> set by 'setlocale'.  I don't expect that to change just because UTF-8
> is used on the outside: internally, everything is converted to UTF-16,
> i.e. to the Windows flavor of wchar_t.
> 
> But this one looks most relevant to your point:
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170#utf-8-support
> 
> 
> "Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C Runtime 
> supports using a UTF-8 code
> page. The change means that char strings passed to C runtime functions can 
> expect strings in the UTF-8
> encoding. To enable UTF-8 mode, use ".UTF8" as the code page when using 
> setlocale. For example,
> setlocale(LC_ALL, ".UTF8") will use the current default Windows ANSI code 
> page (ACP) for the locale and
> UTF-8 for the code page."

This is about UCRT specifically, so I wonder whether MSVCRT will
behave the same.

> My point is, with the manifest embedded at build time, ACP will be UTF-8
> already when the program (Make) runs, so no need to do anything more.

Only on Windows versions that support this.

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

[Eli Zaretskii]

> 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 ucrtbase.dll
> show up in 'ldd make.exe' output, and I wasn't sure what to think of it.
> 
> However, your approach with objdump gives fewer results and only
> lists msvcrt.dll, not ucrtbase.dll:
> 
> C:\Users\cargyris\temp>objdump -p make.exe | grep "DLL Name:"
> DLL Name: ADVAPI32.dll
> DLL Name: KERNEL32.dll
> DLL Name: msvcrt.dll
> DLL Name: USER32.dll
> 
> So I guess MSVCRT is enough, i.e. no need for UCRT.

Yes, thanks.

> > If you try using in a Makefile file names with non-ASCII
> > characters outside of the current ANSI codepage, does Make succeed to
> > recognize files mentioned in the Makefile whose letter-case is
> > different from what is seen in the file system?
> 
> I think it does, here is the experiment:
> 
> C:\Users\cargyris\temp>ls ❎
>  src.c
> 
> There is only src.c in that folder.
> 
> Makefile utf8.mk is UTF-8 encoded and has this content that
> checks for the existence of:
> 
> ❎\src.c
> ❎\src.C
> ❎\src.cs
> 
> where ❎ is outside the ANSI codepage (1252).

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.

> If I understand this correctly, both src.c and src.C should be found,
> but not src.cs (just to show a negative case as well).

In addition, I'm not sure Make actually compares file names somewhere,
I think it just calls 'stat', and that is of course case-insensitive
(because the filesystem is on the base level).

My guess would be that only characters within the locale, defined by
the ANSI codepage, are supported by locale-aware functions in the C
runtime.  That's because this is what happens even if you use "wide"
Unicode APIs and/or functions like _wcsicmp that accept wchar_t
characters: they all support only the characters of the current locale
set by 'setlocale'.  I don't expect that to change just because UTF-8
is used on the outside: internally, everything is converted to UTF-16,
i.e. to the Windows flavor of wchar_t.

> > Btw, there's one aspect where Make on MS-Windows will probably fall
> > short of modern Posix systems: the display of non-ASCII characters on
> > the screen.
> 
> Indeed, some thoughts on that:
> 
> 1) As you know, this is only affecting the visual aspect of the logs, not the
> inner workings of Make.This could confuse users because they would
> be seeing "errors" on the screen, without there being any real errors.
> Perhaps a mention in the doc or release notes could remedy that.
> 
> 2) To some extent (maybe even completely, I don't know) this can be
> mitigated with using PowerShell instead of the classic Command Prompt.
> This seems to be working in this case at least:

This could be just sheer luck: PowerShell uses a font that supports
that particular character.  The basic problem here is that "Command
Prompt" windows don't allow to configure more than one font for
displaying characters, and a single font can never support more than a
few scripts.  If PowerShell doesn't allow more than a single font in
its windows, it will suffer from the same problem.

> If anything, it could be worth a mention in the doc.

Yes, of course.

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

[Eli Zaretskii]

> 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-ASCII characters in programs
> > called by Make, it seems like a clear step forwards in terms of
> > Unicode support on Windows.
> 
> I agree.

Btw, there's one aspect where Make on MS-Windows will probably fall
short of modern Posix systems: the display of non-ASCII characters on
the screen.  Such as the "Entering directory FOO" and echo of the
commands being run by Make.  A typical Windows console (a.k.a.
"Command Prompt" window) can display non-ASCII characters only from a
handful of scripts due to limitations of the fonts used for these
windows, and in addition displaying UTF-8 encoded characters in these
windows using printf etc. doesn't work well.  So users who use such
non-ASCII characters in their Makefiles should expect a lot of
mojibake on the screen.

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

[Eli Zaretskii]

> 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
of the test script, not having them ready in the repository and the
tarball.  That's because unpacking a tarball with non-ASCII characters
and/or having them in Git will immediately cause problems on Windows,
where the unpacking tools and at least some versions of Git for
Windows cannot cope with arbitrary non-ASCII file names.  The Texinfo
project had quite a few similar problems, and ended up generating the
files as part of running the test suite as the only viable solution.

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

[Eli Zaretskii]

> 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 autotools on Windows, just not for building GNU Make.

> > Assuming all questions are answered first, would it be OK to work on
> > the build_w32.bat changes in a second separate patch, and keep the
> > first one focused only on the Unix-like build process?
> 
> Patches can be provided in any order, but until build_w32.bat is
> updated there won't be any testing of these features during the
> "normal" development process.  Presumably (but again, you'll have to
> ask them) the MinGW folks etc. will take release candidate builds and
> verify them in their own environments, once those become available.
> 
> This is not to discourage you in any way: UTF-8 is assumed by GNU Make
> on POSIX systems and getting that to be true on Windows is a big step
> in the right direction IMO!

Indeed.  But build_w32.bat is a very simple batch file, so I don't
think modifying it will present any difficulty.  Let us know if you
need help in that matter.

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

[Eli Zaretskii]

> 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
> doc:
> 
> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

OK, but how is the make.exe you produced built? is it using UCRT or
MSVCRT when it runs?  You can check that by examining the dependencies
of the .exe file with, e.g., the Dependency Walker program
(https://www.dependencywalker.com/) or similar.  Or just use objdump
from GNU Binutils:

  objdump -p make.exe | fgrep "DLL Name:"

and see if this shows MSVCRT.DLL or the UCRT one.

> Does using UTF-8 as the active page in Make mean that locale-dependent
> C library functions will behave as expected?
> 
> I think so.Here is the relevant doc I found:
> 
> https://learn.microsoft.com/en-us/cpp/text/locales-and-code-pages?view=msvc-170

This is not enough.  If locale-dependent C library function still
support only the characters expressible with the ANSI codepage, then a
program using the UTF-8 active codepage will be unable to process the
non-ASCII characters outside of the ANSI codepage correctly.  For
example, downcasing such characters or comparing them in
case-insensitive manner will not work.  This is because for this to
work those functions need to have access to tables of character
properties for the entire Unicode range, not just for the current
locale.  If you try using in a Makefile file names with non-ASCII
characters outside of the current ANSI codepage, does Make succeed to
recognize files mentioned in the Makefile whose letter-case is
different from what is seen in the file system?

> Also, since the above experiments seem to suggest that we are not
> dropping existing support for non-ASCII characters in programs
> called by Make, it seems like a clear step forwards in terms of
> Unicode support on Windows.

I agree.

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

Make is a basic utility used to built others, so we don't require a
full suite of build tools for building Make itself.

> Does this mean that all builds of Make found in the various build
> distributions of the GNU toolchain for Windows (like
> mingw32-make.exe in the examples above) were necessarily built using
> build_w32.bat?

I don't know.  I can tell you that the precompiled binaries I make
available here:

  https://sourceforge.net/projects/ezwinports/files/

are produced by running that batch file.

> Since build_w32.bat is a Windows-specific batch file, does this rule out
> cross-compilation as a canonical way to build Make for Windows?

No, it doesn't rule that out.  But using cross-compilation is not very
important these days, since one can have a fully functional MinGW
build environment quite easily.

> Assuming all questions are answered first, would it be OK to work on the
> build_w32.bat changes in a second separate patch, and keep the first one
> focused only on the Unix-like build process?

Yes.  But my point is that without also changing build_w32.bat the
change is incomplete.

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

[Eli Zaretskii]

> 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 code.This means that any UTF-8 input to make on 
> Windows will break.A few
> examples follow:

Yes, this misfeature of using the system codepage is known, together
with the consequences.

> 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 global effect in the process.All existing "A" 
> calls use the UTF-8 code page now
> instead of the legacy one.This is the relevant Microsoft doc:
> 
> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
> 
> With the patch, after building make, the above cases now work on Windows:
> 
> ##
> C:\Users\cargyris\temp>cat utf8Makefile.mk
> hello :
> @echo ﹏
> @echo ❎
> C:\Users\cargyris\temp>make -f utf8Makefile.mk
> ﹏
> ❎
> 
> C:\Users\cargyris\temp>make -f ❎\utf8Makefile.mk
> ﹏
> ❎
> 
> C:\Users\cargyris\temp>cd ❎
> 
> C:\Users\cargyris\temp\❎>make -f utf8Makefile.mk
> ﹏
> ❎
> 
> C:\Users\cargyris\temp\❎>make -f ❎\utf8Makefile.mk
> ﹏
> ❎
> ##
> 
> This change might also fix other existing issues on Windows having to do with 
> filenames and paths, but I
> can't point at something particular right now.
> 
> Would a patch like that be considered?

Yes, of course.

However, we need to understand better the conditions under which the
UTF-8 support in Make will be activated, and the consequences of
activating it.  Here are some specific questions, based on initial
thinking about this:

  . Does this support require Make to be linked against the UCRT
run-time library, or does it also work with the older MSVCRT?  If
Make is built with MSVC, does it have to be built with some new
enough version of Studio to have the necessary run-time support
for this feature, or any version will do?

  . Does using UTF-8 as the active page in Make mean that
locale-dependent C library functions will behave as expected?  For
example, what happens with character classification functions such
as isalpha and isdigit, and what happens with functions related to
letter-case, such as tolower and stricmp -- will they perform
correctly with characters in the entire Unicode range?  (This
might be related to the first question above.)

  . Did you try running Make with this manifest on older Windows
systems, like Windows 8.1 or 7?  It is important to make sure this
manifest doesn't preclude Make from running on those older
systems, even though the UTF-8 feature will then be unavailable.

  . When Make invokes other programs (which it does quite a lot ;-),
and passes command-line arguments to it with non-ASCII characters,
what will happen to those non-ASCII characters?  I'm guessing that
if the program also has such a manifest, it will get the UTF-8
encoded strings verbatim, but what if it doesn't have such a
manifest?  (The vast majority of the programs Make invokes
nowadays don't have such manifests.)  Will Windows convert the
UTF-8 encoded strings into the system codepage, or will the
program get UTF-8 regardless of whether it can or cannot handle
them?  If the latter, it will become impossible to use non-ASCII
strings and file names with such programs even if those non-ASCII
characters can be represented using the current system ANSI
codepage, because most programs Make invokes on Windows don't
support UTF-8.  Your examples invoked only the built-in commands
of cmd.exe, but what happens if you instead invoke, say, GCC, and
pass it a non-ASCII file name, including a file name which cannot
be represented in the current ANSI codepage?

  . Even if the answer to the previous question is, as I expect, that
Windows will convert UTF-8 encoded strings to the current ANSI
codepage, it is important to understand that with the UTF-8 active
codepage enabled Make will still be unable to invoke programs with
UTF-8 encoded strings if those programs don't have the same UTF-8
active codepage enabled, except if the non-ASCII characters in
those strings can be represented by the current ANSI codepage.  So
this feature will only be complete when the programs invoked by
Make are also UTF-8 capable.

A specific comment on your patch:

> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -46,6 +46,8 @@ w32_SRCS =  src/w32/pathstuff.c src/w32/w32os.c 
> src/w32/compat/dirent.c \
>   src/w32/subproc/misc.c src/w32/subproc/proc.h \
>   src/w32/subproc/sub_proc.c src/w32/subproc/w32err.c

Re: GNU Make 4.4.0.91 on Cygwin

[Eli Zaretskii]

> From: Paul Smith 
> Cc: br...@clisp.org, bug-make@gnu.org
> Date: Mon, 20 Feb 2023 10:36:07 -0500
> 
> Of course "testing on Windows" can mean many different things as there
> are so many possible environments "on Windows".  I only run one Windows
> environment: (a) Windows 10/11 in a VM, (b) using Visual Studio as the
> compiler, (c) using .\build_w32.bat in cmd.exe to do the build, (d)
> running tests from within cmd.exe via ".\WinRel\gnumake.exe check", (e)
> with Git for Windows bin directory on my PATH so I have access to a
> bunch of POSIX tools during the test run.
> 
> It definitely doesn't fail for me in that configuration.
> 
> > Maybe it could work if you link Make statically, or if you copy the
> > dependency DLLs into a system directory where Windows looks
> > regardless of PATH.  But in general, emptying PATH on Windows is not
> > very useful.
> 
> That's missing the point of the test.  Even on POSIX it's useless to
> start a process with an empty PATH, but that's not what the test is
> for.  See https://savannah.gnu.org/bugs/index.php?57674 to read the
> background: on a POSIX system if PATH is not set a default PATH is used
> when we run execvp() and that's what this is testing.
> 
> I don't really know what happens in this situation on Windows, but
> something must happen.

Is your VS-built Make statically linked, or does it have dependencies
on DLLs, such as Guile?  If the latter, in which directories are those
DLLs kept?

My problem with an empty PATH is that the dependency DLLs cannot be
found, and Make simply won't start, because the Windows loader won't
let it.  And even if I work around this by copying the DLLs to the
same directory as the Make executable, there's no point to this test
on Windows, since there's no "default PATH used by execvp" on
MS-Windows.  Moreover, execvp on Windows is emulated (quite poorly,
btw) anyway.

IOW, this Posix feature makes no sense on Windows, so I decided long
ago not to try too hard to run this test.

> It's possible that it works for me because I'm using cmd.exe as the
> shell, and echo is a shell built-in there, and so the fact that PATH is
> empty is irrelevant.

I also use cmd.exe, I just don't have any Git-related Unix programs on
PATH, including Bash and MSYS executables that come with it.  The test
suite runs Perl, so it is very much possible that in your environment,
the Perl that runs is an MSYS perl, not a native Windows perl, in
which case what you get is the Cygwin emulation of Posix (since MSYS
is nothing other than a fork of Cygwin).

In my environment, the perl being used for the test suite is a native
Windows perl (ActiveState Perl).  And any Unix tools the test suite
uses, like 'touch' etc. are all native Windows builds, not MSYS
builds.

Re: GNU Make 4.4.0.91 on Cygwin

[Eli Zaretskii]

> From: Paul Smith 
> Date: Sun, 19 Feb 2023 14:59:35 -0500
> 
> On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote:
> > All "Device or resource busy" failures are gone. Only the 1 failure
> > in category 'misc/general4' is still present.
> 
> Hm.  This is a test of this:
> https://savannah.gnu.org/bugs/index.php?57674
> 
> which explicitly removes PATH from the environment completely.  It
> should use a default PATH, which should mean "echo" works even so.  I'm
> not really sure how this should react on a cygwin system, but I guess
> since it behaves properly on Windows and POSIX it should work on cygwin
> as well.  I'll have to figure out why only cygwin isn't working.

How do you conclude that this "works on Windows"?  In my testing, it
doesn't, and I therefore disable this test on Windows:

  # SV 57674: ensure we use a system default PATH if one is not set
  # This cannot work on MS-Windows, because PATH is used to find
  # shared libraries against which Make was built.
  if ($port_type ne 'W32') {
  delete $ENV{PATH};
  run_make_test(q!
  a: ; @echo hi
  !,
'', "hi\n");
  }

Maybe it could work if you link Make statically, or if you copy the
dependency DLLs into a system directory where Windows looks regardless
of PATH.  But in general, emptying PATH on Windows is not very useful.

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[Eli Zaretskii]

> Date: Sun, 15 Jan 2023 00:57:56 +0900
> From: KO Myung-Hun 
> CC: bug-make@gnu.org
> 
> > How do you mean "make of mingw does not require $(EXEEXT)"?  AFAICT,
> > if the Makefile defines a target FOO, and there's a file FOO.exe that
> > is up to date wrt its dependencies, the MinGW Make will recompile
> > anyway, because it doesn't understand that linking FOO produces
> > FOO.exe.
> > 
> > So I think MinGW and OS/2 are in the same wagon here.
> 
> I've tested make v3.81 for i686-pc-msys shipped with msys.

You are right about MSYS Make, but MSYS is not MinGW, and AFAIK the
patches to Make done by the (now defunct) MSYS team were not
contributed upstream, so we don't know what they changed.

Note, however, that MSYS Make has other goals than MinGW: MSYS is
supposed to emulate Unix enough to allow use of unaltered Unix
Makefile's to build MinGW ports.  So the issue that you are talking
about is an explicit goal for MSYS, more-or-less its raison d'être.
Thus, it is not surprising that MSYS does this.

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[Eli Zaretskii]

> Date: Sat, 14 Jan 2023 23:40:57 +0900
> From: KO Myung-Hun 
> CC: bug-make@gnu.org
> 
> > Please describe the use case in detail.  This situation exists on
> > other platforms, not just of OS/2, and we don't do anything like that
> > for those other targets, AFAIK.  Instead, the Makefile should use
> > $(EXEEXT) or somesuch to account for the issue.  I don't see why OS/2
> > should be handled differently.  But maybe I'm missing something.
> > 
> 
> Yes, I appended $(EXEEXT) if necessary for libiconv, coreutils, and so
> on. BTW, I had a question while doing that. Because only OS/2 required
> $(EXEEXT). Windows platform such as mingw also requires it, but until I
> appended, it had not been there. In practice, make of mingw does not
> require $(EXEEXT).

How do you mean "make of mingw does not require $(EXEEXT)"?  AFAICT,
if the Makefile defines a target FOO, and there's a file FOO.exe that
is up to date wrt its dependencies, the MinGW Make will recompile
anyway, because it doesn't understand that linking FOO produces
FOO.exe.

So I think MinGW and OS/2 are in the same wagon here.

Re: [PATCH] Check .exe as well when a target does not exist on OS/2

[Eli Zaretskii]

> From: KO Myung-Hun 
> Date: Fri, 13 Jan 2023 22:27:43 +0900
> 
> For example,
> 
> foo: foo.c
> gcc $@ $<
> 
> This pattern is usually used on UNIX. However, on OS/2, gcc creates
> foo.exe not foo when an extension is not present, and Make check foo
> only. Therefore Make tries to build foo whenever called.

Please describe the use case in detail.  This situation exists on
other platforms, not just of OS/2, and we don't do anything like that
for those other targets, AFAIK.  Instead, the Makefile should use
$(EXEEXT) or somesuch to account for the issue.  I don't see why OS/2
should be handled differently.  But maybe I'm missing something.

In general, settling for 'foo.exe' when the target is 'foo' can easily
cause false positives, so such a change should IMO not be introduced
without a serious discussion of the possible downsides and
regressions.

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

[Eli Zaretskii]

Follow-up Comment #2, bug #63650 (project make):

??? Do you mean to say that commit f51fc130 caused this regression?  If so, I
don't understand: that commit changed code that is only used on MS-Windows,
whereas the OP is on Arch Linux...



___

Reply to this item at:

  

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

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

[Eli Zaretskii]

Follow-up Comment #15, bug #63638 (project make):

Not sure I understand the problem.  "make ... SHELL=cmd.exe" should do the
trick.



___

Reply to this item at:

  

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

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

[Eli Zaretskii]

Update of bug #63638 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Verified   

___

Follow-up Comment #13:

OK, I've now installed the fix for the bug, and I'm therefore closing this.



___

Reply to this item at:

  

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

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

[Eli Zaretskii]

Follow-up Comment #9, bug #63638 (project make):

OK, then it should be easy for you to build Make by yourself.

First, download the Make sources from here:

   https://ftp.gnu.org/gnu/make/make-4.4.tar.gz

Unpack it (you will need tar.exe or bsdtar.exe).  This will create a directory
make-4.4 with all the sources below it.

Then use some editor to change line 1951 in the file make-4.4/src/variable.c:

  convert_Path_to_windows32 (path, ';');

to say this instead:

  convert_Path_to_windows32 (path + sizeof("PATH=") - 1, ';');

Then invoke the build_w32.bat batch file like this:

  build_w32 gcc --without-guile

This will compile the source files and produce gnumake.exe in the GccRel
subdirectory.  Copy gnumake.exe to somewhere on your PATH and rename it to the
same name you had your original Make executable (I guess either make.exe or
mingw32-make.exe?)

That's it!



___

Reply to this item at:

  

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

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

[Eli Zaretskii]

Follow-up Comment #7, bug #63638 (project make):

Where did you download the Make binaries?

Do you have a MinGW development environment installed (GCC, Binutils, header
files) that allow you to compile C programs?



___

Reply to this item at:

  

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

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

[Eli Zaretskii]

Follow-up Comment #3, bug #63638 (project make):

It is a subtle feature of the native Windows port of GNU Make that it attempts
to support PATH variables delimited by colons and semi-colons alike.  It does
that by converting colon delimiters to semi-colons.  Which is a bit tricky,
given the drive letters with colons.  So Make has some logic to decide when a
colon in PATH is from a drive letter and when it is a delimiter between two
directories.  And a change we made in development of Make 4.4 broke the
fragile logic of that tricky code.

Attached please find a patch to fix this bug.


(file #54209)

___

Additional Item Attachment:

File name: w32path_fix.difSize:0 KB




___

Reply to this item at:

  

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

[bug #63638] the PATH environment variable seems to get modified when a makefile is remade

[Eli Zaretskii]

Follow-up Comment #5, bug #63638 (project make):

(AFAIK, printf debugging is the only way in this case, since GDB on MS-Windows
cannot follow-exec, and we are re-exec-ing ourselves.  My only advantage was
that I knew up from where to put the printf...)

I didn't know about the CSTRLEN macro.  I will use it when I install this
change in Git.  But I'd like first to hear that the OP has his/her real-life
problem fixed by the change, as I'm sure it didn't start from that toy
Makefile.



___

Reply to this item at:

  

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

[bug #16788] 'ORDINARY_MTIME_MAX' macro causes integral constant overflow

[Eli Zaretskii]

Follow-up Comment #4, bug #16788 (project make):

With what compiler? The original warning seems to be from MSVC or maybe
something else, but not from GCC.



___

Reply to this item at:

  

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

Re: [PATCH] Bad sed expression in bootstrap.bat

[Eli Zaretskii]

> From: Paul Smith 
> Cc: gzaf...@gmail.com, bug-make@gnu.org
> Date: Mon, 26 Dec 2022 09:15:56 -0500
> 
> On Mon, 2022-12-26 at 05:29 +0200, Eli Zaretskii wrote:
> > How about reading the Sed script from a file, with the -f command-
> > line argument?
> 
> That would work.  It's annoying to have to add an entirely new file in
> source control just to work around this though.

Well, if that is a problem, you could have bootstrap.bat write that
file for you.  If you do this with "echo", you don't need to worry
about backslash munging, I think, since cmd.exe's "echo" is very
simple-minded, and just blindly copies every character, including the
quotes.

Re: [PATCH] Bad sed expression in bootstrap.bat

[Eli Zaretskii]

> From: Paul Smith 
> Cc: gzaf...@gmail.com, bug-make@gnu.org
> Date: Sun, 25 Dec 2022 21:02:25 -0500
> 
> On Sun, 2022-12-25 at 19:20 +0200, Eli Zaretskii wrote:
> > So this command will work differently depending on which version of
> > Windows it runs, and therefore I would suggest to replace it with
> > something that doesn't need to double or triple backslashes, in order
> > for it to be more portable.
> 
> I would love to do that but I have no idea how.
> 
> The goal is to add a backslash to the end of every line in the file.  I
> don't see a way to do it, without having a backslash on the command
> line.  I'm certainly not even close to an expert in anything Windows
> however.

How about reading the Sed script from a file, with the -f command-line
argument?  In the file you can have whatever you need, and the
contents will not be subject to command-line expansion that creates
this problem.

> > Btw, what is the purpose of the bootstrap.bat file?  It is not part
> > of the Make source tarball, so who and when uses it?
> 
> bootstrap.bat is the counterpart to the bootstrap shell script, for
> when you are running on Windows.  It allows someone to check out the
> Git repository and build it natively on Windows without needing all the
> autotools, etc.  It needs no POSIX tools other than a version of sed.

So it should basically only work for you and no one else?

Re: [PATCH] Bad sed expression in bootstrap.bat

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Sun, 25 Dec 2022 09:06:53 -0500
> 
> On Sun, 2022-12-25 at 02:29 +0100, Giangiacomo Zaffini wrote:
> > I cannot see where
> > sed -e "s/$/ \\/"
> > can be wrong on Windows command line or Windows PowerShell.
> 
> It's because, apparently, cmd.exe sees the "\\" and turns it into a
> single "\" before it invokes the command.  Then the syntax is:
> 
>   sed -e 's/$/ \/'
> 
> which is not legal because the backslash escapes the trailing slash,
> and now there's no trailing slash for the s/// operator.  So you get an
> error.
> 
> If I'm in cmd.exe and I use Perl to show how cmd.exe will interpret the
> command line (using Perl because I know it will be installed if someone
> is running the GNU make test suite; you could use something else if you
> like):
> 
>   C:\Users\user> perl -e "print $ARGV[0];" "s/$/ \\/"
>   s/$/ \/
> 
> note how there's only one "\" here which is wrong and gives an error

Not that it matters much for the purposes of this discussion, but it
is not cmd.exe that does this, it is the startup code of the program
which processes the command line and breaks it into argv[] elements.
The specific function which does that is part of the Microsoft runtime
library.

And one other nit: the working of that function in the Microsoft
runtime has changed between XP and newer systems.  On XP, the original
command, viz.:

  sed -e "s/$/ \\/"

yields the expected "s/$/ \\/" argv element; the backslash is not
eaten.  I see this both in Perl and in a simple C program I have which
just prints its argv[].  So this command will work differently
depending on which version of Windows it runs, and therefore I would
suggest to replace it with something that doesn't need to double or
triple backslashes, in order for it to be more portable.

Btw, what is the purpose of the bootstrap.bat file?  It is not part of
the Make source tarball, so who and when uses it?

[bug #63516] `include` of absolute path prepends path with `./`

[Eli Zaretskii]

Follow-up Comment #8, bug #63516 (project make):

The file name "d:foo" means on Windows "the file 'foo' in the directory that
is current on drive 'd'.  Yes, windows programs can have a separate current
directory on each drive.  You can see that if you do the following dance:

  C:\> cd foobar
  C:\foobar> d:
  D:\> cd quux
  D:\quux> c:
  C:\foobar> dir d:

The last command will show the listing of d:\quux, not of d:\.

IOW, "d:foo" is the same as "d:./foo".

So in my opinion we should treat such file names as absolute, because
prepending a "./" to them is wrong.



___

Reply to this item at:

  

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

[bug #63516] `include` of absolute path prepends path with `./`

[Eli Zaretskii]

Follow-up Comment #5, bug #63516 (project make):

Thanks for the patch.

I have three comments:

(1) The test under "WINDOWS32" should allow a backslash after the colon as
well as a forward slash.

(2) Do we want Make to consider "drive-relative" file names, as in
"d:foo/bar", relative or absolute?  I think the latter, so I suggest not to
require the 3rd character to be a slash, in which case (1) gets solved
automatically.

(3) Unis-style absolute file names, like "/foo/bar", should also be considered
"absolute" on Windows, and likewise "\foo\bar".  Which brings the backslash
issue back.




___

Reply to this item at:

  

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

Re: Old timestamps in the future?

[Eli Zaretskii]

> From: Gisle Vanem 
> Date: Fri, 9 Dec 2022 15:38:08 +0100
> 
> Paul Smith wrote:
> 
> > ... facilities that you don't specify (Cygwin?  MinGW?  WSL?)
> 
> I'm using Cygwin as my POSIX toolbox.
> 
> > But, note that touch writes timestamps in the current timezone by
> > default.  It could be that your timezone (which you also didn't
> > specify) makes a difference, when you are talking about timestamps
> > right at the edge of the epoch.
> > 
> > If you force UTC, for example:
> > 
> >$ TZ=UTC make
> > 
> > does it make a difference in behavior?
> 
> That was it; i.e. no 'has modification time'.

It could mean that your timezone didn't have the date/time you used,
because the Epoch starts at 1970-01-01:00:00 UTC.

Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Orgad Shaneh 
> Date: Thu, 3 Nov 2022 08:29:53 +0200
> Cc: bug-make@gnu.org
> 
> > > Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> > > platform?
> >
> > Indeed, it doesn't currently.  But I wouldn't count on that, some
> > future version could introduce it.
> 
> Is mingw.org still active?

It is, albeit much less so than MinGW64.

> Where can I get it?

   https://osdn.net/projects/mingw/releases

> > _stat64 _is_ supported, but it isn't the default.  So if a program
> > needs to use _stat64, it can only be safely linked against libraries
> > that were also compiled with stat redirected to _stat64, otherwise you
> > cannot safely pass 'struct stat' variables and pointers between the
> > program and those libraries.  And since _stat64 is not the default,
> > the chance that libraries against which you link used it is very
> > small, practically nil.
> 
> * Which libraries?

For example, Guile and all its dependencies.

There's also libmingwex, which provides some functions the MS C
runtime doesn't have.  libmingwex is basically linked into every MinGW
program, since the MinGW startup calls some of those extra runtime
functions.

> * Why should we care what other libraries do? Do we pass struct stat
> to other libraries, or only to system functions?

Are you sure 'struct stat' variables and pointers are never shared
with any libraries against which we link Make libraries?  How can you
be sure of that?  And even if today this is somehow true, will we
remember this tomorrow when we add new code to Make?

This is a time bomb waiting to go off.

Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Jeffrey Walton 
> Date: Wed, 2 Nov 2022 16:22:51 -0400
> Cc: bug-make@gnu.org
> 
> You might also be interested in __MINGW64__.

That's possible, but AFAIK it is only defined after including some
headers; the compiler itself doesn't define it.  Caveat emptor.

> I don't think it's a good idea to try to use MinGW or compiler
> versions as a proxy for 32- or 64-bit time_t. Things are in flux to
> fix the y2038 problem. The debian-arm and debian-powerpc lists are
> having discussions about it now. You will surely encounter 64-bit
> time_t on 32-bit machines eventually.

32-bit Windows have 64-bit time_t variant, but to use it you need to
redirect some function to non-default variants.  'stat' is on of those
functions.

> A first class configure test that checks for the size of time_t will
> probably be your best choice.

As I explained in my other mail, the issue here is not to know whether
the platform _can_ support 64-bit time data types, the issue is what
is the default, because libraries against Make is linked were most
probably compiled with that default.

Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Orgad Shaneh 
> Date: Wed, 2 Nov 2022 22:14:26 +0200
> Cc: bug-make@gnu.org
> 
> On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii  wrote:
> > > Fix by enabling _stat64 also for MinGW.
> >
> > Thanks, but this cannot be done for all MinGW builds.  There's
> > mingw.org's MinGW (which is what I use), and its default is to use
> > 32-bit time_t values.  If you use this change with that MinGW, Make
> > will likely crash at run time, because various libraries it is linked
> > against use a different time_t in stat calls.
> 
> Hi, and thanks for the prompt reply.
> 
> Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> platform?

Indeed, it doesn't currently.  But I wouldn't count on that, some
future version could introduce it.

> Or that it doesn't support _stat64?

_stat64 _is_ supported, but it isn't the default.  So if a program
needs to use _stat64, it can only be safely linked against libraries
that were also compiled with stat redirected to _stat64, otherwise you
cannot safely pass 'struct stat' variables and pointers between the
program and those libraries.  And since _stat64 is not the default,
the chance that libraries against which you link used it is very
small, practically nil.

The same goes for MinGW64, btw: you can only safely redirect stat to
_stat64 there if MinGW64 does that by default.  (I think it does, but
I'm not sure.)

> > So this condition:
> >
> > > -#if defined(_MSC_VER) && _MSC_VER > 1200
> > > +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
> >
> > must be rewritten to catch only MinGW64 builds.  Which would mean a
> > more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.
> 
> I'll try to find something. But first I'll need an answer for the
> previous question, so I know which changes to look for in mingw.

I hope I answered them.

Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Orgad Shaneh 
> Date: Wed, 2 Nov 2022 18:32:49 +0200
> 
> Commit 01142a53c9d (Add support for intmax_t) added support for 64-bit
> time_t by defining __MINGW_USE_VC2005_COMPAT. But this only works with
> _stat64 as expected. When stat is used on 32-bit systems, it returns a
> bad timestamp (for example, 72586185920376753).
> 
> This triggers the following errors every time make is executed:
> mingw32-make: Warning: File 'Makefile' has modification time 7.3e+16 s
> in the future
> mingw32-make: warning:  Clock skew detected.  Your build may be incomplete.
> 
> and of course, dependencies are completely broken.
> 
> Fix by enabling _stat64 also for MinGW.

Thanks, but this cannot be done for all MinGW builds.  There's
mingw.org's MinGW (which is what I use), and its default is to use
32-bit time_t values.  If you use this change with that MinGW, Make
will likely crash at run time, because various libraries it is linked
against use a different time_t in stat calls.

So this condition:

> -#if defined(_MSC_VER) && _MSC_VER > 1200
> +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)

must be rewritten to catch only MinGW64 builds.  Which would mean a
more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.

Re: GNU make 4.3.92 on mingw

[Eli Zaretskii]

> From: Paul Smith 
> Cc: br...@clisp.org, bug-make@gnu.org
> Date: Tue, 25 Oct 2022 14:10:25 -0400
> 
> On Tue, 2022-10-25 at 19:37 +0300, Eli Zaretskii wrote:
> > > A lot of these seem to be CRLF errors in the diff, where it would
> > > otherwise match.  I know that the test framework does some
> > > manipulation of CRLF.
> > 
> > If the test suite runs Diff, it should invoke it with the
> > "--strip-trailing-cr" switch, I think.  Because Cygwin's (and MSYS's)
> > Diff doesn't use Windows text-mode I/O.
> 
> OK I looked into the test suite to remind myself what it does.
> 
> First it compares the base and the log file directly; if they are equal
> we're done.  If they're not equal we manipulate them by (a) converting
> backslash to slash and (b) converting CRLF to LF, then we compare them
> again.  If they're now the same, declare victory.  If they're still
> different, then we invoke diff on the original versions.
> 
> So if we see a difference it must be that there's some OTHER difference
> not just CRLF.  Or, the test suite comparison has a bug.  I'll have to
> look more closely at the output.

I do see differences unrelated to CRLF, see below.

> I don't want to just add that diff switch because it's a GNU diff
> switch and won't work on systems without GNU diff (BSD, etc.)  If I
> wanted to use it I'd need to first check that it was available.  Which
> could be done of course.

MinGW uses only GNU Diff.

Here are the differences I see in the files posted by Bruno.  They
seem to show problems unrelated to EOL format:

> *** work/features/archives.base.1 Tue Oct 25 03:35:39 2022
> --- work/features/archives.log.1  Tue Oct 25 03:35:39 2022
> ***
> *** 1,2 
> ! x86_64-w64-mingw32-ar -rvU libxx.a a2.o
>   a - a2.o
> --- 1,4 
> ! x86_64-w64-mingw32-ar -rvU libxx.a a1.o

> ! r - a1.o
> ! x86_64-w64-mingw32-ar -rvU libxx.a a2.o

>   a - a2.o

This (and other similar diffs in features/archives) seem to indicate
that x86_64-w64-mingw32-ar behaves unexpectedly?

> *** work/features/errors.base.3   Tue Oct 25 03:35:51 2022
> --- work/features/errors.log.3Tue Oct 25 03:35:51 2022
> ***
> *** 1,3 
> ! ./foobarbazbozblat xx yy
> ! make: ./foobarbazbozblat: No such file or directory
> ! make: [work/features/errors.mk.2:2: one] Error 127 (ignored)
> --- 1,4 
> ! ./foobarbazbozblat xx yy

> ! process_begin: CreateProcess(NULL, ./foobarbazbozblat xx yy, ...) failed.

> ! make (e=2): The system cannot find the file specified.


> ! make: [work/features/errors.mk.2:2: one] Error 2 (ignored)


This is a real issue; I patch this (and other) tests to expect the
error messages produced by Make on Windows.

> *** work/features/include.base.36 Tue Oct 25 03:36:06 2022
> --- work/features/include.log.36  Tue Oct 25 03:36:06 2022
> ***
> *** 5,8 
>   GNUmakefile
>   makefile
>   Makefile
> ! make: 'all' is up to date.
> --- 5,9 
>   GNUmakefile
>   makefile
>   Makefile
> ! makefile.mak
> ! make: 'all' is up to date.


This seems to be because Bruno's port of Make is not recognized as
"W32", because features/include does expect makefile.mak then:

  if ($port_type eq 'W32') {
  $defaults = "GNUmakefile\nmakefile\nMakefile\nmakefile.mak";
  } else {
  $defaults = "GNUmakefile\nmakefile\nMakefile";
  }

> *** work/features/jobserver.base.5Tue Oct 25 03:36:07 2022
> --- work/features/jobserver.log.5 Tue Oct 25 03:36:07 2022
> ***
> *** 1,2 
> ! make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> ! make[1]: Nothing to be done for 'foo'.
> --- 1 
> ! make: *** Unknown jobserver auth style 'pipe'.  Stop.


Same here: this test was not supposed to be run for the "W32" port.

> *** work/features/jobserver.base.6Tue Oct 25 03:36:08 2022
> --- work/features/jobserver.log.6 Tue Oct 25 03:36:08 2022
> ***
> *** 1,6 
> ! make: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make[1]: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make[1]: warning: -j1 forced in submake: resetting jobserver mode.
>   hi
> ! make[1]: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> --- 1,6 
> ! make: Entering directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'

> ! make[1]: Entering directory 
> 'C:/cygw

Re: GNU make 4.3.92 on mingw

[Eli Zaretskii]

> From: Paul Smith 
> Date: Tue, 25 Oct 2022 12:07:08 -0400
> 
> On Tue, 2022-10-25 at 16:29 +0200, Bruno Haible wrote:
> > With GNU make 4.3.92, this is down to 75 test failures.
> 
> Just curious how this MinGW test works; are you running the MinGW
> "cross-compiler" installed by the Cygwin package manager, and doing the
> build/test from within a Cygwin shell?
> 
> A lot of these seem to be CRLF errors in the diff, where it would
> otherwise match.  I know that the test framework does some manipulation
> of CRLF.  Maybe it only strips CRLF when it thinks we're running in a
> "Windows" environment, and for some reason this environment is not
> detected properly.

If the test suite runs Diff, it should invoke it with the
"--strip-trailing-cr" switch, I think.  Because Cygwin's (and MSYS's)
Diff doesn't use Windows text-mode I/O.

The tests succeed here, because I made 'diff' a shell script that runs
the "real" Diff with --strip-trailing-cr.  I found long ago that many
test suites have this problem, so I fixed it once and for all.

Re: GNU Make 4.3.92 release candidate available

[Eli Zaretskii]

> From: Paul Smith 
> Date: Mon, 24 Oct 2022 02:59:18 -0400
> 
> I expect this to be the final release candidate before GNU Make 4.4.
> I will probably allow for testing for about a week.
> 
> 
> GNU make is a tool which controls the generation of executables and
> other non-source files of a program from the program's source files.
> 
> You can learn more at: https://www.gnu.org/software/make/
> 
> 
> A new release candidate for GNU make 4.4 is available now for download:
> 
>   724e9144fa841bb1315aee1f2fd8e1d2  make-4.3.92.tar.lz
>   09a2bb194655c99cd9eff23a9128df7f  make-4.3.92.tar.gz
> 
> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

The MinGW port of this builds cleanly and passes the test suite (after
my usual patching of it).

Re: GNU make 4.3.91 on mingw

[Eli Zaretskii]

> From: Bruno Haible 
> Date: Wed, 19 Oct 2022 03:06:51 +0200
> 
> On mingw (on Windows 10 in a Cygwin dev environment), compilation works
> fine, but there are 91 test failures.

FTR: I get only 2 failures in options/dash-q (and for a reason that is
a non-issue: temporary batch files are not removed).  But the test
suite needs to be heavily patched to work with the MinGW port and the
cmd.exe shell.  However, most changes are trivial: different quoting,
different syntax of environment variable expansion, need to use the
GNU 'echo' instead of the shell builtin, .dll extension instead of .so
for loaded extensions, etc.

[bug #63219] Introduce a close function for loadable plugins.

[Eli Zaretskii]

Follow-up Comment #3, bug #63219 (project make):

If we are going to extend the API of the loadable modules, I think we will
have to introduce API versions, because the new API will be
binary-incompatible with the old one, and Make should refuse to load modules
that are incompatible with the API for which it was built.



___

Reply to this item at:

  

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

Re: [PATCH] Fix some temp file issues

[Eli Zaretskii]

> Date: Sat, 8 Oct 2022 21:23:53 -0700
> Cc: bug-make@gnu.org
> From: Paul Eggert 
> 
> On 2022-10-08 21:19, Eli Zaretskii wrote:
> > I meant the "b" part, not the "+" part.  On systems where that changes
> > the bytestream written to the file, the change might require a
> > suitable change where we read that stuff.
> 
> If I understand things correctly the code was formerly using tmpfile 
> which does use "b", so I figured "b" was fine.

Ah, okay.  Then I guess there's no problem after all.

> Another way to think about it: GNU 'make' just writes text to the file. 
> On MS-Windows if you're writing text using "b" doesn't a later read by 
> another process work regardless of whether the read uses "b"?

If the difference is only in EOL format, yes.  But "b" has other
implications, such as reading beyond the first ^Z byte.  Although I
doubt that this could happen in this case.

Re: [PATCH] Fix some temp file issues

[Eli Zaretskii]

> Date: Sat, 8 Oct 2022 15:22:50 -0700
> Cc: bug-make@gnu.org
> From: Paul Eggert 
> 
> On 2022-10-08 00:14, Eli Zaretskii wrote:
> >> tmpfile uses "wb+" (POSIX requires this) and we should be consistent in
> >> all the paths that create temporary FILE *. The attached patch adds a
> >> comment about this.
> > I don't remember: where is this temporary file read?
> 
> It's read by a different process (fork+exec), so it doesn't matter for 
> 'make' now whether it uses "w+" or "w". It matters only for possible 
> future changes to 'make' later, assuming we ever change other parts of 
> 'make' to sometimes need read access via the same FILE *.

I meant the "b" part, not the "+" part.  On systems where that changes
the bytestream written to the file, the change might require a
suitable change where we read that stuff.

Re: [PATCH] Fix some temp file issues

[Eli Zaretskii]

> Date: Fri, 7 Oct 2022 21:37:24 -0700
> Cc: bug-make@gnu.org
> From: Paul Eggert 
> 
> > I'd appreciate a more high-level description of the idea of the
> > change, in addition to the gory details.
> 
> I gave it a shot in the attached patch, which is an improved version of 
> the previous patch.

Thanks, it's more clear now.

> > This opens the file in binary mode where previously it wasn't; what is
> > the rationale for the change?  And why the "+" part?
> 
> tmpfile uses "wb+" (POSIX requires this) and we should be consistent in 
> all the paths that create temporary FILE *. The attached patch adds a 
> comment about this.

I don't remember: where is this temporary file read?  Because that
place where the file is read will most probably need to open the file
in binary mode and/or deal with that when it reads the file.

Re: [PATCH] Fix some temp file issues

[Eli Zaretskii]

> From: Paul Eggert 
> Cc: Paul Eggert 
> Date: Fri,  7 Oct 2022 00:02:25 -0700
> 
> This patch was prompted by a linker warning "warning: the use of
> `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'" on
> Fedora 36.  It also fixes a few unlikely bugs and simplifies the
> code in a couple of places.
> * src/misc.c (get_tmpdir): Now extern, for os_anontmp.
> (get_tmpbase): New function, which generalizes the
> old get_tmptemplate.
> (get_tmptemplate): Use it.
> (get_tmpfifoname): New function, which also uses get_tmpbase.
> Fifo names are now /tmp/GMfifo, where  is the process id;
> there is no need to use mktemp for named fifos as mkfifo refuses
> to create a fifo if the destination already exists, and there is
> no denial of service as GNU Make silently falls back on a pipe if
> the named fifo cannot be created.  Avoiding mktemp saves us some
> syscalls and lets us pacify the glibc linker warning.
> (get_tmppath) [HAVE_MKSTEMP && HAVE_FDOPEN]: Do not define, as
> it's no longer called in this case.  This pacifies the glibc
> linker warning on GNUish platforms.
> (get_tmpfd) [HAVE_DUP && !WINDOWS32]: Use tmpfile for anonymous
> files; on GNU/Linux this avoids a race where the file name is
> temporarily visible.  Avoid two unnecessary calls to umask.
> Report a fatal error if mkstemp or its fallback 'open' fail, since
> the caller expects a nonnegative fd.
> (get_tmpfile) [!HAVE_FDOPEN]: Use tmpfile for anonymous files.
> Simplify.
> * src/os.h (os_anontmp): Now always a function.
> * src/posixos.c (jobserver_setup) [HAVE_MKFIFO]:
> Use get_tmpfifoname instead of get_tmppath.
> (os_anontmp): New function, that avoids making the file
> temporarily visible, on GNUish platforms that support O_TMPFILE.

I'd appreciate a more high-level description of the idea of the
change, in addition to the gory details.  It is not very easy to glean
that from the patch, since it "also fixes a few unlikely bugs and
simplifies the code in a couple of places".

> @@ -644,11 +660,22 @@ get_tmpfd (char **name)
>fd = os_anontmp ();
>if (fd >= 0)
>  return fd;
> +#if HAVE_DUP && !WINDOWS32
> +  mask = umask (0077);
> +  {
> +FILE *tfile = tmpfile ();
> +if (! tfile)
> +  pfatal_with_name ("tmpfile");
> +umask (mask);
> +fd = dup (fileno (tfile));
> +if (fd < 0)
> +  pfatal_with_name ("dup");
> +fclose (tfile);
> +return fd;
> +  }
> +#endif

Why !WINDOWS32 here?

> -  char *tmpnm = get_tmppath ();
> -
> -  /* Not secure, but...?  If name is NULL we could use tmpfile()...  */
> -  FILE *file = fopen (tmpnm, "w");
> +  /* Although the fopen is not secure, this code is executed only on
> + non-fdopen platforms, which should be a rarity nowadays.  */
> +  FILE *file = name ? fopen (*name = get_tmppath (), "wb+") : tmpfile ();

This opens the file in binary mode where previously it wasn't; what is
the rationale for the change?  And why the "+" part?

[bug #63157] Unlink temporary files.

[Eli Zaretskii]

Follow-up Comment #12, bug #63157 (project make):

Thanks, the diffs look good (although I didn't actually test them).



___

Reply to this item at:

  

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

[bug #63157] Unlink temporary files.

[Eli Zaretskii]

Follow-up Comment #10, bug #63157 (project make):

If temp_stdin is fclosed, then there's no need to call close on its fileno.

I don't think I follow your reasoning.  Could you tell more details, including
pointers to the source code?  What do you mean by "We won't be able to use
fclose, which is okay, since make is exiting."?

In general, yes, a file must be closed before we try to unlink it, otherwise
the deletion will fail and the file will not be deleted.



___

Reply to this item at:

  

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

[bug #63157] Unlink temporary files.

[Eli Zaretskii]

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

> If the file is opened at the time of unlink, only file's name is removed
from the directory and the file itself stays. When make exits the last
reference to the file is gone and the file is deleted.

That's what happens on Unix.  On Windows, the unlink call will simply fail
(with EACCES or somesuch), and the file will remain.



___

Reply to this item at:

  

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

[bug #63157] Unlink temporary files.

[Eli Zaretskii]

Follow-up Comment #4, bug #63157 (project make):

This should be tested on MS-Windows.  A file can only be deleted on MS-Windows
if it isn't open by any program, and the patch (AFAICT) doesn't make sure the
files are closed before unlinking them.  I'm especially worried about the
temp_stdin_unlink part.

(Btw, why does the patch use `unlink` instead of a more standard `remove`?)



___

Reply to this item at:

  

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

Re: [PATCH] Port to 32-bit long + 64-bit time_t

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Mon, 03 Oct 2022 16:14:01 -0400
> 
> I needed another set of changes, since intmax_t is a new type and is
> not available on Windows so we needed to add it to configure.ac etc.

By "not available on Windows" you mean in MSVC, right?  Because MinGW
(both flavors of it) does provide it (in stdint.h).

Re: [PATCH] Port to 32-bit long + 64-bit time_t

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Sun, 02 Oct 2022 17:23:46 -0400
> 
> On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
> > (This would not be needed if 'make' used Gnulib's inttypes module.)
> 
> I would be happy to use it, if using it didn't import a ton of other
> things that require POSIX tools AND an already-working make program.
> 
> I understand that this type of reuse makes things easier for the gnulib
> folks, but for GNU make I'm not ready to drop support for platforms
> that are not POSIX enough to run configure, and that don't already have
> "make" available.

It's not just that: some of those platforms aren't even supported by
Gnulib.  For example, DJGPP (a.k.a. "MSDOS") support was AFAIK
dropped, and MinGW (a.k.a. "native MS-Windows") is not supported on
systems older than Windows 7 or 8.1.

Re: Deprecating OS support

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org, Juan Manuel Guerrero 
> Date: Sat, 01 Oct 2022 14:48:01 -0400
> 
> On Sat, 2022-10-01 at 20:42 +0300, Eli Zaretskii wrote:
> > The DJGPP project has been routinely porting all versions of Make up
> > to and including 4.3.
> 
> By "DJGPP project" I expect you are referring to the MSDOS port (I'm
> not familiar with all the alternative names).

Yes.  DJGPP is the MSDOS port of GNU development tools, based on GCC
and GNU Binutils.

> The thing that I'm specifically looking at in the code are ifdef's
> using __MSDOS__.  Are these the ifdefs used by DJPP?

Yes.

Re: Deprecating OS support

[Eli Zaretskii]

> From: Paul Smith 
> Date: Sat, 01 Oct 2022 13:02:55 -0400
> 
> With the upcoming release (4.4) I intend to announce that I'll be
> removing support for the following platforms in the next, post-4.4
> release:
> 
>   - OS/2 (EMX)
>   - Amiga
>   - Native MS-DOS
> 
> For the first two, I suspect that whatever support we currently have is
> broken and it's not really possible to build GNU make, even today, for
> those platforms.  I haven't received any input from anyone using those
> platforms in years and it's hard for me to believe that, with all the
> changes, everything still "just works".
> 
> I'm less sure about native MS-DOS.  Maybe someone still uses this?

The DJGPP project has been routinely porting all versions of Make up
to and including 4.3.  For the latest announcement, see

  
https://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2022/06/07/17:09:13

> If anyone thinks that any of these should be preserved and I should not
> announce deprecation for them, let me know.

Juan (CC'ed) has been providing all the latest ports of Make, so I'll
let him answer these questions.

Re: GNU make 4.3.90 release candidate available

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Mon, 26 Sep 2022 15:14:37 -0400
> 
> > Some binaries from Git for Windows are MinGW binaries, but some are
> > MSYS2 binaries.  All those for which Git Bash says they are in /bin
> > (as opposed to /mingw64/bin) are MSYS2 binaries, they depend on MSYS
> > DLL and don't use the Windows C runtime.  MSYS2 is a fork of Cygwin,
> > with a few subtle features that allow it to invoke native Windows
> > programs without confusing them with Unix-style file names and PATH.
> 
> To be honest I still don't think I understand all the intricacies of
> this.  All I know is that I add:
> 
>   set "PATH=%PATH%;C:\Strawberry\perl\bin;C:\Git\usr\bin"

C:\Git\usr\bin holds MSYS2 executables, not MinGW executables.  (MinGW
executables that come with Git are in C:\Git\mingw64\bin.)  So
basically, you are running the tests in the MSYS2 environment, the
only exclusion from that is make.exe itself.

Re: GNU make 4.3.90 release candidate available

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Mon, 26 Sep 2022 14:23:40 -0400
> 
> On Mon, 2022-09-26 at 20:23 +0300, Eli Zaretskii wrote:
> > The following tests should be disabled on MS-Windows, because they
> > cannot possibly work:
> 
> I have access to a VM running Windows 10 with a relatively recent
> Visual Studio install, with a recent Perl, and with the Git for Windows
> binaries (from MinGW I assume) on my PATH.  No other cygwin or MinGW.

Some binaries from Git for Windows are MinGW binaries, but some are
MSYS2 binaries.  All those for which Git Bash says they are in /bin
(as opposed to /mingw64/bin) are MSYS2 binaries, they depend on MSYS
DLL and don't use the Windows C runtime.  MSYS2 is a fork of Cygwin,
with a few subtle features that allow it to invoke native Windows
programs without confusing them with Unix-style file names and PATH.

> In this environment I can do this (in a Windows cmd.exe shell):
> 
>   tar xzf make-4.3.90.tar.gz
>   cd make-4.3.90
>   .\build_w32.bat
>   .\WinRel\gnumake.exe check
> 
> This builds with Visual Studio and I get zero test failures.
> 
> I assume a big part of this is that make is choosing bash as its shell,
> from the Git for Windows install, not cmd.exe.  Plus other POSIX tools
> are available.

Of course, it's because you set up Bash as the shell Make uses!  Which
means many tests run in an environment that will rarely happen in Real
Life, when the native port of Make is used with cmd.exe as the shell,
not with MSYS2 Bash.

The tests do need a few Unix tools (like 'sleep', 'cat', 'touch', and
maybe others), but those are available as native MinGW ports; whereas
Bash isn't.  Moreover, when a Makefile uses the MSYS2 Bash, it will
generally invoke MSYS2 binaries of other tools, like 'cat' and 'touch'
(unless you are very careful to set up your PATH for Git Bash).  So
you end up using "foreign" tools to run the tests, and I find that
less than optimal.  (It is, of course, much less time-consuming ;-)

> >  . 1 test in misc/bs-nl that uses single quotes around newlines
> >  . 1 test in misc/general3 that uses single quotes around newlines
> >  . 1 test in misc/general4 that unsets PATH (this cannot work on
> >    Windows because Make will be unable to find the DLLs against which
> >    it was linked, so it fails to start without valid PATH)
> >  . targets/ONESHELL in its entirety (this feature doesn't work on
> >    Windows)
> 
> I assume most/all of the above really mean, these tests won't work on
> Windows when make uses a Windows shell such as cmd.exe.

The last two should fail with MSYS Bash as well, I think.

> Maybe we need to add a new check to the test framework that sets a
> variable depending on what kind of shell make is using, then this
> variable should be used when deciding which tests to run rather than
> using "are we on Windows or not".

Feel free, but what's the point of artificially making the tests
"succeed" by forcing them to run in the MSYS environment?  What does
it gain us for testing the native MS-Windows port of Make?  MSYS has
its own port of GNU Make, one that uses largely the Posix code paths
and bypasses the Windows-specific parts (for example, they use the
job-server for parallelism).

> >  . targets/POSIX in its entirety
> 
> The .POSIX: special target tells make that it should modify its
> behavior to conform to the POSIX specification of make, in places where
> it might differ by default.  This happens on Windows the same as on
> non-Windows.

Yes, but look what is being tested there.  I could, of course, tweak
those tests to succeed on native Windows, but what's the point?  E.g.,
this:

  # Test the default value of various POSIX-specific variables
  my %POSIX = (AR => 'ar', ARFLAGS => '-rv',
   YACC => 'yacc', YFLAGS => '',
   LEX => 'lex', LFLAGS => '',
   LDFLAGS => '',
   CC => 'c99', CFLAGS => '-O1',
   FC => 'fort77', FFLAGS => '-O1',
   SCCSFLAGS => '', SCCSGETFLAGS => '-s');

Does it really make sense to jump through hoops in order to test this
on Windows?