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

[Joel Sherrill]

Jim Wilson wrote:

> 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.
>
No.  It definitely applies to all of the gnat* tools but since gnatmake 
is needed to build
the toolset it tripped over it disappearing from target to target.

> 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.
>
But it is building a cross gnat1.  This is a cross build and it is 
touching a native file.  That
seems very broken.  The cross gnat1 can't be incompatible with a native 
gnatmake -- they
should be independent.

> 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.
>
I couldn't agree with you more on this as a long term solution.  If 
enabling ada automatically
built the gnat* tools and the run-time were a top-level package, 
everything would just
work out nicely.  It also solves the multilib issues.

Whether this is worth fixing or not is up for grabs.  It is a marginal 
case but kind of
hard to see what exactly is happening.  Sometimes changing the procedure 
is enough
to close something.

Are there "official" cross gnat build instructions?  Making sure they 
can't lead to this
situation would be enough to make me happy for now.

> 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.

That would work as does moving the order around so the gnattools are 
built and installed.
So cross all that were are delaying is the compilation of the run-time.

--joel