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

[Paul D. Smith]

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

I just mean writing a test that's portable.  I can try again hard-coding SHELL
and restricting the test to only run on Windows, or something like that.


___

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

[Paul D. Smith]

Update of bug #63638 (project make):

 Assigned to:None => eliz   
   Triage Status:Verified => Medium Effort  

___

Follow-up Comment #14:

I made a stab at trying to write a test for this but it's too hard, since you
have to be sure you're using cmd.exe as the SHELL etc. else the PATH is
rewritten.


___

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

[anonymous]

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

Okay I'll do that as soon as I can.
Thanks again for your help with the PATH issue.

Best regards.


___

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

[Paul D. Smith]

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

You definitely should but you'll have to do more debugging, ideally giving a
repro case as you did for the PATH issue.  It may be challenging: our
regression tests for output-sync are not failing so I don't think the problem
is obvious.

We did make non-trivial changes to how output sync works on POSIX systems but
I don't think we (intentionally) changed anything related to this on Windows
systems.


___

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

[anonymous]

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

Indeed, I followed your instructions and I can confirm that the PATH bug is
now gone. Thank you kindly.
However, as you suspected, my real application still does not build
successfully...

It seems to be an unrelated problem, though. My parallel build is successful
when using --output-sync=none, but its stalls indefinitely at various points
when using --output-sync=target (which is not the case with Make 4.3)

I should probably open a separate report for this, right?


___

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

[anonymous]

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

I downloaded the Make binaries through MSYS2 with:
pacman -S mingw-w64-x86_64-make

Yes, I have a MinGW development environment installed and I can 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 #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

[anonymous]

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

Eli, Paul, thanks a lot for finding the cause of the problem so quickly!

I am just an end user of make, though, and to be quite honest I don't know how
to apply your patch, rebuild make, and test my real-life Makefile.
(I'm really sorry about that)

The minimal Makefile I posted is the result of tracking down the problem I had
my real-life Makefile and reducing it to its essence, which makes me pretty
confident about the fact that your patch will indeed fix my problem.

That being said, if you're willing to attach your patched .exe, I'll be more
than happy to try it right away.

Please let me know if you need any more information,

Thanks again.


___

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

[Paul D. Smith]

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

Ah, I see.  I spent about 30m last night trying to find this but since I don't
really do Windows development I was reduced to printf debugging and couldn't
come up with it before I had to go to dinner :).

That was my fault breaking this.  That change makes sense to me (although I'd
use the CSTRLEN("PATH=") macro), thanks for finding it Eli!

It would be good if we could add a test for this, since the code is as you
say, tricky.  I'll think about how to do 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 #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 #63638] the PATH environment variable seems to get modified when a makefile is remade

[anonymous]

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

Thank you very much for your quick response, Paul. Good to know that you can
reproduce this behavior.
I'll switch back to 4.3 for now. Thanks again for your time,
Best regards





___

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

[anonymous]

Additional Item Attachment, bug #63638 (project make):

File name: Makefile   Size: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

[anonymous]

URL:
  

 Summary: the PATH environment variable seems to get modified
when a makefile is remade
 Project: make
   Submitter: None
   Submitted: Mon 09 Jan 2023 10:01:07 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Mon 09 Jan 2023 10:01:07 PM UTC By: Anonymous
Consider the following minimal example:

# ---

# show the content of the environment variable PATH

$(info PATH = $(shell echo %PATH%))


# the first time the makefile is made, we delete the (empty) file we're
including below.
# this ensures that its rule gets executed and that the makefile gets remade.

ifeq ($(MAKE_RESTARTS),)
$(shell del missing_at_first.mk)
endif


# the first time the makefile is made, this file doesn't exist, but we have a
rule to create it, so we are going to get remade

include missing_at_first.mk


# rule to create an empty file

missing_at_first.mk:
@type nul > missing_at_first.mk

# ---

with make 4.4-2, i get the following result:

PATH = C:\msys64-make-4.4-2\mingw64\bin
PATH = C;\msys64-make-4.4-2\mingw64\bin

please notice how the first colon turned to a semicolon on the second pass.

with make 4.3, i get the expected result:

PATH = C:\msys64-make-4.4-2\mingw64\bin
PATH = C:\msys64-make-4.4-2\mingw64\bin








___

Reply to this item at:

  

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