Re: On the toplevel configure and build system

["Joseph S. Myers" <joseph@codesourcery.com>]

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