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
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
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
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
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
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
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]
