This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: rfc: new libgcc build mechanism


%% Phil Edwards <pedwards@jaj.com> writes:

Rats, the last one got away from me.  Please ignore it.

  >> I haven't looked closely at this, but I will note right off that this:

  dt> "CC=$$(echo $$(case '$(CC)' in (stage*) echo '$(CC)' | sed -e

  >> is very non-portable.

  pe> I have looked at this even less closely than you; perhaps I have
  pe> missed something.  If you are constructing the makefile via
  pe> autoconf, why not detect a shell that will do such expansions and
  pe> set SHELL in the output makefile accordingly?

If you can find one, that's fine.  First you are assuming that every
platform you want to build GCC on _will_ have such a shell.  Since ksh
isn't free, and certainly not every UNIX includes bash, some versions of
UNIX might not have one anywhere (is this the same thread where we were
discussing the limitations of 4.3BSD sh?)

Second, you are assuming we can find them; UNIX vendors are notoriously
sneaky about where they stow these things, and also what they name
them.  I don't relish the thought of providing a long list of potential
hiding places and aliases for shells within autoconf :-/.

Third, testing for all these features would be a pain.  Not a huge pain,
but a pain nonetheless.

I still believe we can do what we need to do without these features.  I
provided an implementation of the example given which I believe DTRT for
all shells... no?

  pe> Also, just FYI, the default make on Solaris (from the development
  pe> tools package, sitting in /usr/ccs/bin) is the same make as the
  pe> POSIX-complaint make, so it would pay attention to the SHELL
  pe> setting:

Sure, that's not the problem.  I've never heard of _ANY_ make that
didn't obey the SHELL variable.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@baynetworks.com>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]