Makefile.in FLAGS_TO_PASS: why pass *_FOR_TARGET variables?

[Jeffrey A Law]

  In message <9807310051.AA30078@marc.watson.ibm.com>you write:
  > 	I have been tracking down some build problems on AIX 4.3 and have
  > become confused about the intent of some of the *_FOR_TARGET variables
  > passed using FLAGS_TO_PASS.  This variable includes a number of flag
  > variables such as GCC_FOR_TARGET, AR_FOR_TARGET, and RANLIB_FOR_TARGET.
  > FLAGS_TO_PASS is used when calling subsidiary language Makefiles, but none
  > of those Makefiles utilize any of the _FOR_TARGET variables other than
  > GCC_FOR_TARGET.
Some of them are for use by other packages which are not a part of
egcs (like the simulator, binutils, gdb, newlib, libgloss, etc).

Remember, the toplevel Makefile.in and configury is actually useable
for building much more than just egcs.

  > 	The "gcc" Makefile defines many variables as their _FOR_TARGET
  > counterparts because "We always act like a cross-compiler, even when we're
  > compiling native."  It seems to me that passing the _FOR_TARGET variables
  > has no effect, unless I am missing something.  Those variables are used in
  > the "gcc" Makefile, but nowhere else.
Well, the comments in gcc/Makefile.in claim that the toplevel Makefile
can provide overriding definitions.  But I suspect that comment is
now how of date.


  > 	Because AR and RANLIB obtain their correct values in the "gcc"
  > Makefile, I think that the variables themselves should be passed, as
  > LDFLAGS and CFLAGS, etc. already are.  One could pass
  > 
  > 	"AR=$(AR_FOR_TARGET)"
  > 
  > but $(AR) already has the correct value, so just pass "AR=$(AR)".
The toplevel Makefile has to make a distinction between HOST and TARGET
tools.  Consider if you're building cross tools.

AR is the host ar
AR_FOR_TARGET is the target ar

These will have different values when building cross tools.  Or am
I missing the point somewhere?

jeff