Re: PATCH: Support the new demangler written in C++

["H. J. Lu" <hjl at lucon dot org>]

On Tue, Jul 08, 2003 at 02:04:03AM -0300, Alexandre Oliva wrote:
> On Jul  8, 2003, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > On Mon, Jul 07, 2003 at 07:04:01PM -0700, H. J. Lu wrote:
> >> > 
> >> > Assuming this is supposed to go in anyway, please make sure you spell
> >> > TARGET correctly (it's TERGET in your patch), and move
> >> > ALL_TARGET_LIBIBERTY closer to the other ALL*_LIBIBERTY macros.  Also,
> >> > make sure they expand to not only maybe-all*-demangler, but also
> >> > maybe-all*-libiberty.  The way it is now, should the demangler
> >> > directory not be there, it wouldn't build libiberty at all.
> >> 
> >> I will fix those.
> 
> > Here is the new patch with those changes.
> 
> Thanks.  I don't have any technical issues with this patch.  I'd only
> like to see a comment added before the ALL*_LIBIBERTY definitions
> explaining why everybody should be using these instead of
> all*-libiberty, with the exception of libstdc++-v3, even if they don't
> care about the demangler.  Namely, it's for parallel make safety.  I
> do realize now that the reason libstdc++-v3 can do it is that
> demangler depends on it libstdc++, so libiberty will never be updated
> by demangler while libstdc++ is building.

Here is the new patch. I also changed demangler. Now it won't compile
demangler when it is included in gcc.

> 
> However, I won't approve this patch for now, because the decision of
> whether to introduce a new build requirement for a complete libiberty,
> even one disguised as it is, is something that the maintainer of
> libiberty should decide whether to approve and impose on its users.

I'd like a yes or no answer.


H.J.

Attachment: demangler-11.patch.bz2
Description: BZip2 compressed data