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

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

On Mon, Jul 07, 2003 at 09:13:13PM -0400, Nathanael Nerode wrote:
> HJL asked:
> > Any comments?
> First of all, it seems unnecessary and undesirable to use recursive 
> Makefile techniques in the demangler directory.  Is it possible to 
> rearrange it so that there's just Makefile.am, not Makefile.am and 
> lib/Makefile.am?

The current directory structure is easier to extend for a standalone
demangler.

> 
> Second, it's not such a great idea to have *everything* which depends on
> libiberty now, be made to depend on demangler.  In particular, I'm 
> pretty sure texinfo, sim, and sid don't need it, and I'm quite sure that 
> diff, fastjar, fileutils, flex, gzip, hello, m4, make, patch, prms, 
> recode, sed, tar, and uudecode don't.  I'm also pretty sure 
> target-fastjar, target-libf2c, and target-libobjc don't.  There may be
> others.

It is for parallel make. Otherwise, libiberty.a may be changed or
disappear when something is linking against it.

> 
> Third, you misspelled "ALL_TARGET_LIBIBERTY" as "ALL_TERGET_LIBIBERTY".
> Fourth, I don't think introducing new Makefile macros is necessary; list
> the demangler explicitly on the lines where it's needed.

Will fix that.

> 
> Fifth, you used test -a.  Don't; use && instead.
> 

Will fix that.

> Sixth, I still don't understand the interrelationship between libiberty
> and demangler in your patch.  Could you explain it one more time? :-)
> 
> Seventh, if we're doing this, is there a reason we still have 
> cplus-dem.o (the *old old* demangler), or am I missing something?

The new demangler needs a working C++ compiler, which may not be
available when

1. There is no working C++ compiler. In that case, we use the old
demangler.
2. We are building the C++ compiler and libstdc++. But the new
demangler needs libstdc++, which depends on libiberty. We build
the target demangler after libstdc++ is done.


H.J.