>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Akim> Still, for my own education, I would like to be taught why it
Akim> would make sense.
Tom> Locally we put everything into a single tree, which you can
Tom> configure with one command. This is really handy if we want to,
Tom> say, ship a version of "make" to our customer. It means less
Tom> work in release engineering.
Sure, I understand.
Tom> However, "make" doesn't use --target. Still, it gets passed in
Tom> by the top-level configure.
I understand this, although I'd understand better with --host. So
actually what you are teaching me is that you do ship
cross-compiling suites, i.e., a set of cross-compilation tool such as
sun4-gcc, sun4-ld etc., but also a sun4-make which is actually just a
standard make, right?
Tom> You could argue that the top-level configure should just know
Tom> which subdirs use --target and which do not. However, I consider
Tom> that to be a bad idea. It violates modularity and is harder to
Tom> maintain.
Absolutely.
Tom> I think it shouldn't even be a warning. I think configure should
Tom> accept --target silently just as it does not.
Ian and you do agree on this point. In fact, much of this thread is
precisely on this point. Pavel says, IIUC, that it does do harm to
some people to use --target when they meant something else. I
understand now why it would be wrong to issue an error for this issue.
I think I also understand why you don't want a warning: warnings are
not there to help newbies to make sure they meant what they did, but
their mission is to diagnose really abnormal situations, right?
And giving --target to a package which doesn't care about $target is
not considered abnormal, right?
Is it right to:
- not document --target etc. when the AC_CANONICAL_TARGET etc. is not
used?
- change the defaults to
1. build ?= config.guess
2. host ?= build
3. target ?= host
- remove the support of HOST on the command line, because it is
incorrect to map this HOST to a virtual --host=HOST
?
Akim
