Re: weirdness with ada/Make-lang.in on 3.4 branch

[Jim Wilson <wilson at specifixinc dot com>]

Joel Sherrill wrote:
> make                make install       if ada
>  make cross-gnattools
>  make ada.all.cross
>  make gnatlib  make install
>
> This used to use the LANGUAGE override to avoid getting ada at all.
> Now the above procedure ends up with gnat1 installed as before the
> "if ada" and the 1st make install gets confused because there is a
> gnat1 but no gnatmake.

This idiom is used in many places in the Ada Make-lang.in file, so it 
isn't just gnatmake that is a problem.

Deleting the native gnatmake if it wasn't built seems like a generally 
useful thing to do, otherwise, you might end up with incompatible gnat1 
and gnatmake installed if you really are building a native.  So if we 
modified the Ada Makefile, I think we would have to add explicit tests 
for native/cross builds, and then it will get a bit more complicated. 
It isn't clear that the extra complexity is worthwhile.

I think the proper solution would be to reorganize the Ada support so 
that gnatlib and gnattools and separate top level directories.  One can 
then adjust the order of building them so that they build after newlib. 
 We could also then pass in flags so that they can find and use newlib 
in the build tree such as is done for other libraries.  We have been 
waiting for this for a long time already though.

Meanwhile, you could avoid the mess if you use the --enable-languages= 
configure option.  This means you have to configure and build gcc twice. 
 The first time you only build C and newlib.  The second time you build 
everything.  This has the advantage that some libgcc stuff will be built 
that otherwise might not be, such as the profiling support.  This gets 
you back something similar to what you had when you used LANGUAGES.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com