sync_Path_environment issue

[LM]

I'm trying to build make 3.82 using MinGW (32 bit) in an msys environment.
When I test the results out by attempting to rebuild autoconf with this
version of make, I hit the following error:
cfg.mk:21: *** Recursive variable `PATH' references itself (eventually).
Stop.

The line that's causing the trouble for make is:
export PATH = $(shell echo "`pwd`/tests:$$PATH")

It's not that there are two instances of PATH in the command. I can change
the second PATH to any variable name I want and I still get the error. I
can change PATH = to PATH := and I don't get the error. It looks like when
make sees PATH =, it assumes it's working with a variable it needs to
expand (with f_recursive not f_simple). To get the rest of the variable,
it tries to call the shell and run the echo command. For Windows only,
before calling CreateProcess to run anything (such as the shell command),
there's a call to sync_Path_environment. So, Windows is probably the only
platform where make will run into this error. In variable.c,
sync_Path_environment, there's a call to:
char *path = allocated_variable_expand ("$(PATH)");
That's the same PATH variable that's being set by cfg.mk. So, make is
trying to expand and bring back the value of the variable recursively. In
expand.c, recursively_expand_for_file, v->expanding gets set, v->exp_count
is not equal 0, so the error message comes up.

Not sure of the best fix for this. Still investigating that part. By the
time, PATH is looked up in sync_Path_environment, it appears to have
already started to redefine the PATH variable to $(shell echo
"`pwd`/tests:$$PATH"). When sync_Path_environment tries to evaluate PATH,
it needs to shell out to do so, thus sync_Path_environment gets called
recursively and the recursive PATH error occurs.

[Eli Zaretskii]

Date: Tue, 21 May 2013 09:02:57 -0400
I'm trying to build make 3.82 using MinGW (32 bit) in an msys environment.
When I test the results out by attempting to rebuild autoconf with this
version of make ^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^

This is your problem, right there: The MinGW Make is not supposed to
run in the MSYS environment. Use the MSYS provided Make instead.
Even if this problem is somehow solved, you will hit others further
down the road. The main problem is that the MSYS Bash wants to see
and outputs /d/foo/bar file names that the MinGW Make does not
understand.

The _only_ sane way to build packages under MSYS is to use the MSYS
Make.

export PATH = $(shell echo "`pwd`/tests:$$PATH")
It's not that there are two instances of PATH in the command. I can change
the second PATH to any variable name I want and I still get the error. I
can change PATH = to PATH := and I don't get the error.

I actually wonder why Autoconf doesn't use := to begin with. It is
the right way.

It looks like when make sees PATH =, it assumes it's working with a
variable it needs to expand (with f_recursive not f_simple). To get
the rest of the variable, it tries to call the shell and run the
echo command. For Windows only, before calling CreateProcess to run
anything (such as the shell command), there's a call to
sync_Path_environment.

That call is required, because the "normal" environment used by the C
runtime library is separate from the environment block used by
CreateProcess. That call synchronizes them. Without it, we will have
much more serious problems.

Not sure of the best fix for this.

If you find a fix that doesn't remove the call to
sync_Path_environment, I will review it and see if it can be
accepted. But please note that you are trying to solve a problem you
shouldn't bump into in the first place. Just use MSYS Make.

[LM]

Post by Eli Zaretskii
If you find a fix that doesn't remove the call to
sync_Path_environment, I will review it and see if it can be
accepted. But please note that you are trying to solve a problem you
shouldn't bump into in the first place. Just use MSYS Make.

So msys make does not have the same issue with recursive calls to
sync_Path_environment? I'd be interested to see what's different in the
build that it avoids it. I did notice msys make is still on 3.81 instead
of 3.82, so I would expect it to have some differences just because of
version changes.

I'm using msys as a build environment for now, but final target environment
will use another bash-like shell besides msys on Windows, that's why I
didn't start by trying to build msys make. I don't know if msys make will
work properly with other shells besides msys sh.exe. If it doesn't, it
won't be of any use to me.

Thanks for the information.

[Eli Zaretskii]

Date: Tue, 21 May 2013 15:40:34 -0400
So msys make does not have the same issue with recursive calls to
sync_Path_environment?

I'd be surprised to hear it does.

I'd be interested to see what's different in the build that it
avoids it.

It simply does not compile that code into the binary.

I did notice msys make is still on 3.81 instead of 3.82

You can find snapshots of much newer versions floating around, I use
one such snapshot (because I needed to be able to run parallel
builds).

I'm using msys as a build environment for now, but final target environment
will use another bash-like shell besides msys on Windows, that's why I
didn't start by trying to build msys make.

Which Bash-like shell exists on Windows, except Cygwin?

I don't know if msys make will work properly with other shells
besides msys sh.exe. If it doesn't, it won't be of any use to me.

You can always use := if you bump into this very problem in your
target environment with the native MinGW Make.

[LM]

Post by Eli Zaretskii
Which Bash-like shell exists on Windows, except Cygwin?

I've seen ports of zsh and tcsh for Windows. Not exactly bash syntax, but
useful shells. There's a bash like shell with the win32 busybox port.
There's an older bash-nt project at Sourceforge. The MirOS project has a
developer working on porting mksh to Windows. The project I'm working with
is in the process of developing a bash-like shell with added
internationalization support based on msh. I even noticed support for the
MKS shell mentioned in the make code. So, there are other options besides
msys and/or Cygwin based bash shells.

You can always use := if you bump into this very problem in your

Post by Eli Zaretskii
target environment with the native MinGW Make.

If that's true, then a simple work-around would be to add code like the
following at the beginning of do_variable_definition in variable.c:

#ifdef WINDOWS32
if (strcmp (varname, "PATH") == 0)
{
if (flavor == f_recursive)
flavor = f_simple;
}
#endif

It should only be executed by the native Windows port and it would prevent
ever running into a recursive case if one is setting the PATH variable.


If you find a fix that doesn't remove the call to

Post by Eli Zaretskii
sync_Path_environment, I will review it and see if it can be
accepted.

Rhetorical question, but why would someone want to remove
sync_Path_environment? It's obviously been added for a purpose and if one
removes it, one changes the state of the program.

[Eli Zaretskii]

Date: Thu, 23 May 2013 07:29:46 -0400

Post by Eli Zaretskii
Which Bash-like shell exists on Windows, except Cygwin?

I've seen ports of zsh and tcsh for Windows.

They are buggy (even after I fixed some glaring bugs in zsh). Only
usable for very simple jobs.

There's a bash like shell with the win32 busybox port.

If that means one needs to install busybox, then it's not really
compelling...

There's an older bash-nt project at Sourceforge.

Tried that; buggy and limited.

The MirOS project has a developer working on porting mksh to
Windows. The project I'm working with is in the process of
developing a bash-like shell with added internationalization support
based on msh.

I'll be delighted to see these work once they are developed.

I even noticed support for the MKS shell mentioned in the make code.

That's proprietary, so I'm not interested. I want something I can fix
when I find a bug.

So, there are other options besides msys and/or Cygwin based bash
shells.

Not really, not if you want to run configure scripts or something
similar in complexity.

Post by Eli Zaretskii
You can always use := if you bump into this very problem in your
target environment with the native MinGW Make.

If that's true, then a simple work-around would be to add code like the
#ifdef WINDOWS32
if (strcmp (varname, "PATH") == 0)
{
if (flavor == f_recursive)
flavor = f_simple;
}
#endif

Is it really a fact that PATH on Windows must be non-recursive? I'm
not sure.