Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman <[EMAIL PROTECTED]> writes: > Alexandre Julliard wrote: >> The MAKEFLAGS hack is certainly non portable, and won't behave right >> on other makes. Using a shell script will also cause trouble on >> Windows. The extra shell evaluation will also require some extra >> quoting, that may be tricky to get right. It's really a lot of >> trouble... > > I'm guessing you still believe this is the case, even with my latest patch. Well, the quoting is fixed, but the rest isn't... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Alexandre Julliard wrote: Robert Shearman <[EMAIL PROTECTED]> writes: I don't see how. It doesn't change the portability with other versions of make, and although I'm not an expert on shell programmings, I don't think I used an non-portable constructs there. The MAKEFLAGS hack is certainly non portable, and won't behave right on other makes. Using a shell script will also cause trouble on Windows. The extra shell evaluation will also require some extra quoting, that may be tricky to get right. It's really a lot of trouble... I'm guessing you still believe this is the case, even with my latest patch. -- Rob Shearman
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman <[EMAIL PROTECTED]> writes: > I don't see how. It doesn't change the portability with other versions > of make, and although I'm not an expert on shell programmings, I don't > think I used an non-portable constructs there. The MAKEFLAGS hack is certainly non portable, and won't behave right on other makes. Using a shell script will also cause trouble on Windows. The extra shell evaluation will also require some extra quoting, that may be tricky to get right. It's really a lot of trouble... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Alexandre Julliard wrote: I've been thinking about this some more, and I don't think I'll put it in. It's going to cause a lot of trouble and portability headaches, for only a minor cosmetic gain. I don't see how. It doesn't change the portability with other versions of make, and although I'm not an expert on shell programmings, I don't think I used an non-portable constructs there. -- Rob Shearman
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman <[EMAIL PROTECTED]> writes: > I've also modified tools/makerule to respect the "-s" flag passed into make. > > Alexandre suggested on IRC that I always print the destination file, > but I want to make sure that the technical details of this patch are > acceptable before making tweaks to the printed commands. I've been thinking about this some more, and I don't think I'll put it in. It's going to cause a lot of trouble and portability headaches, for only a minor cosmetic gain. This thing really belongs in make itself; it shouldn't be hard to patch GNU make to have a mode where it only displays the command name and target instead of the whole command line. Then it would work for all projects, and wouldn't require adding complexity to the makefiles. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman a écrit : The old behaviour can be turned back on by setting the V environment variable to "1" (e.g. make V=1). a couple of more comments (mostly not yet converted rules): - the MAKEDEP rule in Make.rules.in isn't handled yet (suggestion [DEPEND] $SRC(DIR)) - most of exec rule in tools/*/Makefile.in miss the MAKERULE stuff - ditto in loader (and the version-stamp could be handled too) - in dlls/Makedlls.rules.in, all lib/def/.a stuff isn't handled is there any reason why the Linking... rule has a different format than the others ? now I wish we could also get rid of the message for recursive calls to make A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman a écrit : The old behaviour can be turned back on by setting the VERBOSE environment variable to "yes". .s.o: $(AS) -o $@ $< $(MODULE): $(OBJS) Makefile.in - $(RM) $@ - $(AR) $@ $(OBJS) - $(RANLIB) $@ + @$(RM) $@ + @$(MAKERULE) '[AR] $@' $(AR) $@ $(OBJS) + @$(MAKERULE) '[RANLIB] $@' $(RANLIB) $@ we'll miss the echo for the $(RM) command in verbose mode IMO, we should use here something like @$(MAKERULE) '' $(RM)... and handle the empty $1 in makerule A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)