This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Ada] multilib patch take three
> Yes I volunteer. We're in stage1 so we have some time to sort out
> reported issues before release.
OK. I'm still concerned that there is no simple fallback for all targets
that will break, except for --disable-multilib which is too strong since
it impacts other languages.
I'd be much more confortable with e.g. adding a --disable-mutilibada
or some such that would basically fall back to the previous state.
> Only libada/Makefile.in install will be invoked for all multilib
> by the install machinery so gcc/ada/Makefile.in install cannot
> do properly the rts install work anymore, hence the change. The relevant
> libada/Makefile.in parts are now:
What about people using disable-multilib or --disable-libada ? I'd rather
keep the part in ada/Makefile.in for these cases.
> +install-gnatlib: $(GCC_DIR)/ada/Makefile
> + $(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) \
> + libsubdir="$(libsubdir)" \
> + install-gnatlib
> +
>
> # Installation rules.
> -install:
> +install: install-gnatlib
> + $(MULTIDO) DO=install multi-do # $(MAKE)
Well, I still do not understand how install-gnatlib works in the new scheme,
I guess I need more detailed explanation, since I am not familiar with
multilib scheme. Could you explain in details how make install will install
the various gnatlibs in the new scheme ?
> Tactically I can submit the mechanical parts of the patch separately
> since it obscures the rest of the patch which is otherwise quite simple:
>
> <<
> The patch touches lots of gcc/ada/Makefile.in but hopefully 99% of the
> change is mechanical:
>
> 1/ replace all use of "rts" by "$(RTSDIR)"
> 2/ replace all use of "stamp-gnatlib*" by "stamp-gnatlib*-$(RTSDIR)"
>
> Once these changes are in place by setting RTSDIR one can build
> multiple Ada rts without conflict from gcc/ada/Makefile.in
> >>
It probably indeed makes sense to submit this separately. I see that you've
modified this from your first patch for gnattools, right ?
> I think this will help review and this is useful change on its own,
> should I test and submit this first part separately?
Yes, although I'd wait for the tuples branch and gcc-interface restructuration
which will happen end of july/beginning of august.
> PS: I did start some review of PAIRS but I could not find the "marte"
> runtime sources in SVN:
> a-exetim.adb<a-exetim-linux-marte.adb \ ...
> Is it a commit oversight?
This is not an oversight, this code is not suitable for the FSF (for
one thing it is copyrighted). Having the Makefile change reduces the differences
between AdaCore and FSF makefiles, which is highly desirable from a maintenance
point of view.
Arno