On Tue, 29 Mar 2011, DJ Delorie wrote: > > 2. If you put directories from the GCC repository into your build, you > > should expect GCC and its libraries to be built; toplevel should not > > disable GCC on the grounds that GCC does not support a given target. > > I disagree. We have a single combined gcc+binutils+etc internal tree > that's used for many targets; some support gcc, some do not. I added > another "don't build gcc for this" just last week.
Well, disabling gcc for targets where it is unsupported is hardly consistent existing practice in the FSF tree; before my patch <http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02027.html> there were just two targets (c54x*-*-* | tic54x-*-*, v810-*-*) disabling the gcc directory, so that patch makes things consistent with the normal practice for non-gcc-supporting targets by removing those special cases. I don't however object much to toplevel disabling gcc on targets without support (if you have a GCC-only tree, it *does* seem unfortunate for configuring it for an unsupported target to quietly build nothing and exit with status 0, instead of exiting with error status), as long as it is done consistently in accordance with principle 4: that is, through config.gcc being adapted so toplevel configure.ac can use it to get positive information from the gcc/ directory about supported targets, rather than through negative declarations at toplevel for unsupported targets. And much the same applies to other components in a unified tree: negative declarations that something is unsupported are much worse than positive information from a subdirectory about what is supported there, and it would be good for one-component-only trees to be able to give meaningful errors if nothing useful gets built - maybe some check is needed to give errors if no installed host tool or target library would be built. -- Joseph S. Myers jos...@codesourcery.com
