Re: On the toplevel configure and build system

Joseph S. Myers
2011-03-29T23:29:29Z

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
joseph@codesourcery.com