RE: rfc: new libgcc build mechanism

[Donn Terry <donnte at microsoft dot com>]

Please take a look at the Makefile in that area; the
current code is using nested `` to create further command
lines (not data files).  I'll admit I haven't tried, but
I'm not at all sure it can be done because the *creation*
of the string occurs in a different directory than the
*use* of it, and the purpose of the substitution is to
deal with that problem!  Here's what I currently use
locally (with $()).  If you can figure out a decent
(and generally acceptable) solution to the problem that
works with ``, I'll be more than happy to see it.

PREPEND_DOTDOT_TO_RELATIVE_PATHS = sed \
        -e 's|^ *[^ /][^ /]*/|%&|' \
        -e 's| -B| -B%|g' \
        -e 's|% *[^- /]|%&|g' \
        -e 's|%% *|../|g' \
        -e 's|%||g'
SUBDIR_FLAGS_TO_PASS = $(ORDINARY_FLAGS_TO_PASS) \
        "CC=$$(echo $$(case '$(CC)' in (stage*) echo '$(CC)' | sed -e
's|stage|../stage|g';; (*) echo '$(CC)';; esac) |
$(PREPEND_DOTDOT_TO_RELATIVE_PATHS) )"

I'm also trying to avoid gmake features (that could do the
substitution inside make) and recursive make calls (in the
same directory), which end up being just plain confusing.

(Note... this is a Makefile line... I'm sure you know but
let me remind you (because it's an easy mistake to make)
that the $(CC) is substituted within make, and it's the
$$() constructs that become the shell substitutions we're
talking about.)

Donn

> -----Original Message-----
> From: Felix Lee [mailto:flee@teleport.com]
> Sent: Tuesday, May 09, 2000 11:42 AM
> To: Donn Terry
> Cc: 'Robert Lipe'; 'Russ Allbery '; 'autoconf@gnu.org ';
> 'gcc@gcc.gnu.org '
> Subject: Re: rfc: new libgcc build mechanism
> 
> 
> Donn Terry <donnte@microsoft.com>:
> > The current partial solution involves having two 
> the-same-but-different
> > versions of the same string, with different levels of \ quoting
> > of ` (to allow nesting of `).
> 
> what do you gain from nesting `` that you can't do by using
> temp variables?  I can't think of a case where they aren't
> equivalent.
> --
>