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 ma
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 cert
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 be
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'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 twea
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 rul
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]
