automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.


From: Ralf Wildenhues
Subject: Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.
Date: Wed, 15 Sep 2010 23:56:00 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

For now, I didn't get any further than just some comments upon comments
(a review-review, if you like):

* Stefano Lattarini wrote on Wed, Sep 15, 2010 at 01:45:17AM CEST:
> On Tuesday 14 September 2010, Peter Rosin wrote:
> > Den 2010-09-14 20:14 skrev Stefano Lattarini:
> > >> +     [am_ar_try='$AR cru libconftest.a conftest.$ac_objext 
> > >> >&AS_MESSAGE_LOG_FD'
> > > 
> > > What is the rationale for not redirecting stderr here, along with
> > > stdout?
> > 
> > But stderr is redirected?
> Where?  Am I mising something?

By AC_TRY_EVAL.

> > >> +      AC_TRY_EVAL([am_ar_try])

[...]
> > Ok, can you please hold that until after this is through the pipe
> > though, so that I don't have to fixup when merging?

Peter, you shouldn't have to worry about any merging issues.  That's
what working on a branch is for, and that's what the msvc branch is for.

Irrespective of which branch gets merged to master in what order, that
doesn't necessarily mean the last one to merge gets the burden to fixup.
In case of doubt, the maintainer does.

By the way, if a merge requires more than trivial cleanup, it's probably
not the cleanest idea to do a fake merge, but to do the cleanup in a
separate patch beforehand, or to merge the other way first or so.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]