[bug #30614] Output redirection with &> not parsed correctly in make 3.81 and up

2010-07-31 Thread Joey Adams 

Follow-up Comment #1, bug #30614 (project make):

Update:

The issue turned out to be make using /bin/sh instead of bash.  Only the
latter supports the &> syntax.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #30614] Output redirection with &> not parsed correctly in make 3.81 and up

2010-07-31 Thread Joey Adams 

URL:
  

 Summary: Output redirection with &> not parsed correctly in
make 3.81 and up
 Project: make
Submitted by: joeyalanadams
Submitted on: Sun 01 Aug 2010 04:46:57 AM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

Given the following Makefile:

all:
@echo "You shouldn't be seeing this." &> /dev/null

GNU Make 3.80 has the expected behavior, which is to redirect stdout/stderr
to /dev/null .

3.81, 3.82, and CVS do not redirect either stdout or stderr.  Instead, the
echo command is backgrounded, and the output appears in the terminal.

If I replace &> with >& (which also works in GNU Make 3.80):

all:
@echo "You shouldn't be seeing this." >& /dev/null

I get the following error message:

/bin/sh: Syntax error: Bad fd number
make: *** [all] Error 2

Here is a workaround for redirecting stdout/stderr that does work in GNU Make
3.81 and up:

all:
@(echo "You shouldn't be seeing this." 2>&1) > /dev/null




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: including makefile name and line number for shell_function_completed

2010-07-31 Thread Philip Guenther 
On Sat, Jul 31, 2010 at 4:54 PM, Jon Grant  wrote:
> I am using make 3.81 built for MinGW.
>
> How easy to output the Makefile.mak:line for each command that fails to start?

I don't think there's any way for a snippet of Makefile to figure out
what its line # and filename are.  The $(warning) function will
include them in its output, but I don't see any way to trigger that
based on the success or failure of a command without completely
changing how the makefile operates.

Hmm.

So, what's needed is for a future version of GNU make to provide some
way to get the current filename and line number.  Now, that could mean
a number of things.  The *obvious* answer would be to provide
$(filename) and $(linenumber) functions that expand to the line number
and filename where they are expanded.  I'm 80% sure that that's the
right choice.  Consider the following sort of makefile:
--
define rules
echo "build $@ at $(filename):$(linenumber)"
@touch $@
endef

foo:
$(rules)
--

Should the reported line number be that of the use of $(rules), or
should it be where $(linenumber) was writen?  I'm mostly convinced
that the answer is the former, but I have slight misgivings and I
suspect there are places where someone would want immediate expansion.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: insufficient debug info from gnu-make

2010-07-31 Thread Philip Guenther 
On Sat, Jul 31, 2010 at 7:19 PM, Peter Lawrence
 wrote:
> On Jul 31, 2010, at 9:41 AM, Eli Zaretskii wrote:
>>>           one thing I remember in detail about Sun's make, is that
>>> instead of writing a level number
>>>
>>> make[3]: ...
>>> make[2]: ...
>>> make[1]: ...
>>>
>>> it wrote out the directory that the commands had cd'ed to before
>>> recursing (and maybe the file name, can't be sure any more)
>>>
>>> make[foo/bar]: ...
>>> make[foo]: ...
>>> make[.]: ...
>>
>> GNU Make displays the equivalent "Entering directory foo..." and
>> "Leaving directory foo..." messages.  Isn't that the same info?
>
> the words "Entering" and "Leaving" never appear in the output I captured

So are you going to read the GNU make info pages to see what
conditions make will generate those messages and how something might
have suppressed them?  Perhaps the gcc maintainers have decided that
they hate those messages and have told GNU make to not generate them.
If so, complaining to make developers will result in absolutely no
progress.  You need to figure out who actually has control over the
stuff that's bugging you.


> typical output from gnu-make when making gcc is such
> tossed-salad-scrambled-eggs that nothing is readable,
> most lines are hundreds of characters long, as you can
> see below the average is over 400 chars/line, here is
> some sample output from my failed build, you can't
> really tell much of anything from reading this output

That problem (monstrously long compile lines) has absolutely nothing
to do with make and there's nothing that make can do about it.  That's
just a problem with the makefile itself and needs to be taken up with
the authors of that.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

including makefile name and line number for shell_function_completed

2010-07-31 Thread Jon Grant 
Hello

I am using make 3.81 built for MinGW.

How easy to output the Makefile.mak:line for each command that fails to start?

I saw this function is what outputs the error, but not sure how to get
file and line number info. Any ideas?

Thanks, Jon

shell_function_completed

if (werr)
  fprintf(stderr, "make (e=%d): %s",
  exit_code, map_windows32_error_to_string(exit_code));

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: insufficient debug info from gnu-make

2010-07-31 Thread Peter Lawrence 


On Jul 31, 2010, at 9:41 AM, Eli Zaretskii wrote:


From: Peter Lawrence 
Date: Sat, 31 Jul 2010 07:41:49 -0700
Cc: bug-make@gnu.org

   one thing I remember in detail about Sun's make, is that
instead of writing a level number

make[3]: ...
make[2]: ...
make[1]: ...

it wrote out the directory that the commands had cd'ed to before
recursing (and maybe the file name, can't be sure any more)

make[foo/bar]: ...
make[foo]: ...
make[.]: ...


GNU Make displays the equivalent "Entering directory foo..." and
"Leaving directory foo..." messages.  Isn't that the same info?



the words "Entering" and "Leaving" never appear in the output I  
captured
typical output from gnu-make when making gcc is such tossed-salad- 
scrambled-eggs
that nothing is readable, most lines are hundreds of characters long,  
as you can see
below the average is over 400 chars/line, here is some sample output  
from my failed build,

you can't really tell much of anything from reading this output

-Peter Lawrence.



> vi make.log
> wc !$
wc make.log
 976   18655  407334 make.log
>

- sample  

-DTARGET_MACHINE=\"powerpc-apple-darwin8.11.0\" \-c ../../gcc-4.3.3/ 
gcc/collect2.c -o collect2.o
/Users/peterl/GNUSTUFF/gcc/objdir/./gcc/xgcc -B/Users/peterl/GNUSTUFF/ 
gcc/objdir/./gcc/ -B/Users/peterl/GNUSTUFF/installdir//powerpc-apple- 
darwin8.11.0/bin/ -B/Users/peterl/GNUSTUFF/installdir//powerpc-apple- 
darwin8.11.0/lib/ -isystem /Users/peterl/GNUSTUFF/installdir//powerpc- 
apple-darwin8.11.0/include -isystem /Users/peterl/GNUSTUFF/ 
installdir//powerpc-apple-darwin8.11.0/sys-include -c   -O2 -g -g - 
O2   -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes - 
Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute  
-pedantic -Wno-long-long -Wno-variadic-macros -DHAVE_CONFIG_H -I.  
-I. -I../../gcc-4.3.3/gcc -I../../gcc-4.3.3/gcc/. -I../../gcc-4.3.3/ 
gcc/../include -I./../intl -I../../gcc-4.3.3/gcc/../libcpp/include -I/ 
Users/peterl/GNUSTUFF/installdir//include -I/Users/peterl/GNUSTUFF/ 
installdir//include -I../../gcc-4.3.3/gcc/../libdecnumber -I../../ 
gcc-4.3.3/gcc/../libdecnumber/dpd -I../libdecnumber../../ 
gcc-4.3.3/gcc/tlink.c -o tlink.o/Users/peterl/GNUSTUFF/gcc/objdir/./ 
gcc/xgcc -B/Users/peterl/GNUSTUFF/gcc/objdir/./gcc/ -B/Users/peterl/ 
GNUSTUFF/installdir//powerpc-apple-darwin8.11.0/bin/ -B/Users/peterl/ 
GNUSTUFF/installdir//powerpc-apple-darwin8.11.0/lib/ -isystem /Users/ 
peterl/GNUSTUFF/installdir//powerpc-apple-darwin8.11.0/include - 
isystem /Users/peterl/GNUSTUFF/installdir//powerpc-apple-darwin8.11.0/ 
sys-include   -O2 -g -g -O2   -DIN_GCC   -W -Wall -Wwrite-strings - 
Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - 
Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic- 
macros -DHAVE_CONFIG_H  -o Tcollect2 \collect2.o tlink.o  
intl.o version.o ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../ 
libiberty/libiberty.a ../libdecnumber/libdecnumber.a/usr/bin/ld:  
warning multiple definitions of symbol _locale_charset./../intl/ 
libintl.a(localcharset.o) definition of _locale_charset in section  
(__TEXT,__text)/usr/lib/libiconv.dylib(localcharset.o) definition of  
_locale_charsetmv -f Tcollect2 collect2
--- sample  
-




___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: insufficient debug info from gnu-make

2010-07-31 Thread Eli Zaretskii 
> From: Peter Lawrence 
> Date: Sat, 31 Jul 2010 07:41:49 -0700
> Cc: bug-make@gnu.org
> 
>one thing I remember in detail about Sun's make, is that  
> instead of writing a level number
> 
> make[3]: ...
> make[2]: ...
> make[1]: ...
> 
> it wrote out the directory that the commands had cd'ed to before  
> recursing (and maybe the file name, can't be sure any more)
> 
> make[foo/bar]: ...
> make[foo]: ...
> make[.]: ...

GNU Make displays the equivalent "Entering directory foo..." and
"Leaving directory foo..." messages.  Isn't that the same info?

___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: insufficient debug info from gnu-make

2010-07-31 Thread Peter Lawrence 

Paul,
  one thing I remember in detail about Sun's make, is that  
instead of writing a level number


make[3]: ...
make[2]: ...
make[1]: ...

it wrote out the directory that the commands had cd'ed to before  
recursing (and maybe the file name, can't be sure any more)


make[foo/bar]: ...
make[foo]: ...
make[.]: ...


even that simple tidbit of information is really useful.!!.


-Peter Lawrence.








On Jul 29, 2010, at 9:54 PM, Paul Smith wrote:


On Thu, 2010-07-29 at 21:09 -0700, Peter Lawrence wrote:
make[3]: *** No rule to make target `real-install-headers-tar'.   
Stop.


This is printed when you've invoked make and the target you asked  
for on

the command line cannot be created (for example you ran "make foo" but
the makefile has no target "foo" defined).  There's no line number or
filename information to provide, here, because the request came  
from the

command line, not from inside the makefile.


here is where the offending command originates:

$(MAKE) real-$(INSTALL_HEADERS_DIR) DESTDIR=`pwd`/../gcc/ \
 libsubdir=. ; \


So the sub-make is the one that generated the error message, and as I
mentioned it can't give you information about what line of the parent
make's makefile was the problem (just like your C compiler has no  
way to

tell you what line of the makefile it was invoked from).

All that could be done in this case is that the parent make could be
asked to show filename/linenumber information for the target that  
failed

(that is, the error after the error you quote above).


I'm certainly not asserting that GNU make couldn't do a better job
giving error messages with more details regarding where the error
happened, I'm just saying that this particular case is not quite so
clear-cut as it may appear at first.

--
-- 
-

 Paul D. Smith   Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." -- 
Mad Scientist





___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #30612] make-3.82 parse error

2010-07-31 Thread Peter Breitenlohner 

URL:
  

 Summary: make-3.82 parse error
 Project: make
Submitted by: breitenlohner
Submitted on: Sat 31 Jul 2010 02:20:49 PM GMT
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: CVS
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

make 3.82 fails to parse a dependency 'util.a(foo.o bar.o)', as demonstrated
by the attached self-contained Makefile. Whereas this Makefile works fine with
3.81, 3.82 yields:
  *** No rule to make target `util.a(foo.o', needed by `util.a'



___

File Attachments:


---
Date: Sat 31 Jul 2010 02:20:50 PM GMT  Name: Makefile  Size: 223B   By:
breitenlohner
Makefile demonstrating the problem


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make