Another clue into my problem with make...

Another clue into my problem with make...

[Robert Bresner]

Howdy again

The new details:
	1. Before, my make problem was limited to emacs, but I've
	been informed that the problem exists in an NT cmd.exe
	session as well ( but not on my machine. ) Could this be
	an environment thing? (What environment variables are 
	used by make? I know SHELL. Is WORK? Of the 2 books I have
	on make, only one mentions SHELL. )

	2. Before, the PATH was getting _blown away_ [ PATH=(null) ],
	but I've now seen where an NT style path (e.g. w:\my_path)
	is being changed to a *nix style path, after an NT mount
	(e.g. //w/my_path). That is just incredibly odd. Does 
	GNU make check the Cygwin mount table? 
	
The Recap:
	NT4 SP1-5
	Cygwin 20.1 (?) and/or cygwin1-19990115.dll 
	   ( but this problem has existed for years, 
	     across several installations )
	GNU Make version 3.76.1

The Problem:
	During a very large and complicated make induced
	build, the PATH is arbitrarily lost, so various
	tools in the build cannot be found and executed,
	thus the build fails.

The original details:
	By arbitrarily, I mean that 
		a) it doesn't happen to everyone.
		b) it doesn't always happen.
	I cannot establish a pattern beyond the fact that it
	_usually_ happens after a certain Perl script runs, but
	not always, and within a relatively few directories 
	( the whole build is about 130 directories building 
	  some 2 million lines of code ), but not always.
	The Perl script has been extensively checked and double-
	checked by the resident Perl gurus, and it is not the
	cause of the problem (also confirmed by the fact that
	it runs with no problems in 128 other dirs, on various
	platforms, on 80 other machines). 
		
	
Hoping the new details will jog a memory for someone.
This wouldn't be such an issue, except that it is
worse for some people than others, and the problem 
has been spreading. (Up to 6 people who occasionally
experience it, and one fellow has it happen _every day_.
He's the most vehement about finding a solution, as one
might imagine. )

Thanks in advance for any help...


----------------------------------------
Robert Bresner          rbresner@olf.com
Open Link Financial    516-227-6600 x216
http://www.olf.com/    fax: 516-227-1799
----------------------------------------
Opinions expressed are explicitly my own
"No more talking!  Cerebus has a SWORD!"

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Another clue into my problem with make...

[Christopher Faylor]

On Wed, Jun 23, 1999 at 05:13:58PM -0400, Robert Bresner wrote:
>	2. Before, the PATH was getting _blown away_ [ PATH=(null) ],
>	but I've now seen where an NT style path (e.g. w:\my_path)
>	is being changed to a *nix style path, after an NT mount
>	(e.g. //w/my_path). That is just incredibly odd. Does 
>	GNU make check the Cygwin mount table? 

Any cygwin application changes the path from MS-DOS format to UNIX
format automatically, so this is not surprising.

Sorry, but I have no other insight into your problem.  The translation
to POSIX format is not surprising, though.

cgf	

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

make 3.76 has path problems? (was Another clue into my problem with make...)

[Robert Bresner]

With this makefile:

	default:
		@path
		@echo PATH: $(PATH)

NT E:\static\olf>make-3.76
PATH=c:\enscript; ...
PATH: c:\enscript; ...

NT E:\static\olf>make-3.75.exe 
make-3.75.exe 
PATH=c:\enscript; ...
PATH: /enscript: ...

NT E:\static\olf>make-3.75.exe --win32
PATH=c:\enscript; ...
PATH: /enscript: ...

make v3.76 is not always doing the 'right thing' with paths ?
Which leads me to think that it is possibly responsible for
knocking out my path during the complicated builds. 

Christopher Faylor wrote:
> Any cygwin application changes the path from MS-DOS format to UNIX
> format automatically, so this is not surprising.


Again, the symptoms we experienced here happened without a 
recognizable pattern. Sometimes no problems, sometimes
path = (null), sometimes path = unix-style-path. 
If unix-style-path is the right thing, then make 3.76 
just isn't doing that, as shown with the very simple
makefile example above..

Remarkable and indescribable thanks to you guys for helping me
out. I never, ever, would have solved this problem on my own.

----------------------------------------
Robert Bresner          rbresner@olf.com
Open Link Financial    516-227-6600 x216
http://www.olf.com/    fax: 516-227-1799
----------------------------------------
Opinions expressed are explicitly my own
"No more talking!  Cerebus has a SWORD!"

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: make 3.76 has path problems? (was Another clue into my problem with make...)

[Chris Faylor]

On Thu, Jun 24, 1999 at 02:36:55PM -0400, Robert Bresner wrote:
>With this makefile:
>
>	default:
>		@path
>		@echo PATH: $(PATH)
>
>NT E:\static\olf>make-3.76
>PATH=c:\enscript; ...
>PATH: c:\enscript; ...

This indicates that your make-3.76 was not built using cygwin.  So, it is not
going to know about cygwin paths.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

make 3.76 has path problems? (was Another clue into my problem with make...)

[Robert Bresner]

With this makefile:

	default:
		@path
		@echo PATH: $(PATH)

NT E:\static\olf>make-3.76
PATH=c:\enscript; ...
PATH: c:\enscript; ...

NT E:\static\olf>make-3.75.exe 
make-3.75.exe 
PATH=c:\enscript; ...
PATH: /enscript: ...

NT E:\static\olf>make-3.75.exe --win32
PATH=c:\enscript; ...
PATH: /enscript: ...

make v3.76 is not always doing the 'right thing' with paths ?
Which leads me to think that it is possibly responsible for
knocking out my path during the complicated builds. 

Christopher Faylor wrote:
> Any cygwin application changes the path from MS-DOS format to UNIX
> format automatically, so this is not surprising.


Again, the symptoms we experienced here happened without a 
recognizable pattern. Sometimes no problems, sometimes
path = (null), sometimes path = unix-style-path. 
If unix-style-path is the right thing, then make 3.76 
just isn't doing that, as shown with the very simple
makefile example above..

Remarkable and indescribable thanks to you guys for helping me
out. I never, ever, would have solved this problem on my own.

----------------------------------------
Robert Bresner          rbresner@olf.com
Open Link Financial    516-227-6600 x216
http://www.olf.com/    fax: 516-227-1799
----------------------------------------
Opinions expressed are explicitly my own
"No more talking!  Cerebus has a SWORD!"

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: make 3.76 has path problems? (was Another clue into my problem with make...)

[Chris Faylor]

On Thu, Jun 24, 1999 at 02:36:55PM -0400, Robert Bresner wrote:
>With this makefile:
>
>	default:
>		@path
>		@echo PATH: $(PATH)
>
>NT E:\static\olf>make-3.76
>PATH=c:\enscript; ...
>PATH: c:\enscript; ...

This indicates that your make-3.76 was not built using cygwin.  So, it is not
going to know about cygwin paths.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Another clue into my problem with make...

[Robert Bresner]

Howdy again

The new details:
	1. Before, my make problem was limited to emacs, but I've
	been informed that the problem exists in an NT cmd.exe
	session as well ( but not on my machine. ) Could this be
	an environment thing? (What environment variables are 
	used by make? I know SHELL. Is WORK? Of the 2 books I have
	on make, only one mentions SHELL. )

	2. Before, the PATH was getting _blown away_ [ PATH=(null) ],
	but I've now seen where an NT style path (e.g. w:\my_path)
	is being changed to a *nix style path, after an NT mount
	(e.g. //w/my_path). That is just incredibly odd. Does 
	GNU make check the Cygwin mount table? 
	
The Recap:
	NT4 SP1-5
	Cygwin 20.1 (?) and/or cygwin1-19990115.dll 
	   ( but this problem has existed for years, 
	     across several installations )
	GNU Make version 3.76.1

The Problem:
	During a very large and complicated make induced
	build, the PATH is arbitrarily lost, so various
	tools in the build cannot be found and executed,
	thus the build fails.

The original details:
	By arbitrarily, I mean that 
		a) it doesn't happen to everyone.
		b) it doesn't always happen.
	I cannot establish a pattern beyond the fact that it
	_usually_ happens after a certain Perl script runs, but
	not always, and within a relatively few directories 
	( the whole build is about 130 directories building 
	  some 2 million lines of code ), but not always.
	The Perl script has been extensively checked and double-
	checked by the resident Perl gurus, and it is not the
	cause of the problem (also confirmed by the fact that
	it runs with no problems in 128 other dirs, on various
	platforms, on 80 other machines). 
		
	
Hoping the new details will jog a memory for someone.
This wouldn't be such an issue, except that it is
worse for some people than others, and the problem 
has been spreading. (Up to 6 people who occasionally
experience it, and one fellow has it happen _every day_.
He's the most vehement about finding a solution, as one
might imagine. )

Thanks in advance for any help...


----------------------------------------
Robert Bresner          rbresner@olf.com
Open Link Financial    516-227-6600 x216
http://www.olf.com/    fax: 516-227-1799
----------------------------------------
Opinions expressed are explicitly my own
"No more talking!  Cerebus has a SWORD!"

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Another clue into my problem with make...

[Christopher Faylor]

On Wed, Jun 23, 1999 at 05:13:58PM -0400, Robert Bresner wrote:
>	2. Before, the PATH was getting _blown away_ [ PATH=(null) ],
>	but I've now seen where an NT style path (e.g. w:\my_path)
>	is being changed to a *nix style path, after an NT mount
>	(e.g. //w/my_path). That is just incredibly odd. Does 
>	GNU make check the Cygwin mount table? 

Any cygwin application changes the path from MS-DOS format to UNIX
format automatically, so this is not surprising.

Sorry, but I have no other insight into your problem.  The translation
to POSIX format is not surprising, though.

cgf	

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com