This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bootstrap failure on Linux/x86-64 in Ada
> You can set it for gcc/ada only, not for the benefit of the entire
> tree. It makes it hard, for example, to make libada really its own
> toplevel directory, because T_ADAFLAGS is set within the gcc target
> fragments.
Well, so you're saying there will be, in the future, a potential
problem with T_ADAFLAGS. Fine, but this is not a problem today.
I do not think it is a good idea to try to fix everything at the same time.
> Personally, I think that the way ADAFLAGS is specified is too
> error-prone. I understood that Kenner said, -gnatg is necessary on the
> language components, but is actually removing a legitimate warning for
> other files such as the compiler.
No, that's a misunderstanding. -gnatg is necessary for language components,
and also required for all GNAT files, for various reasons.
> I believe that -gnatg should be set
> manually on the files that need it (within gcc/ada/Makefile.in).
Well possibly but as I said, that wouldn't fix any particular problem.
> Similarly, -gnatp -gnata should be in some way linked to gcc's
> --enable-checking mechanism.
That's confused (as you had guessed). -gnata could indeed be linked to
--enable-checking, but -gnatp not. -gnatp is also highly recommended
by default (and certainly when --disable-checking), and should only be
removed in very special circumstances, which probably do not justify
a configure option (and in any case, configure option are a pain, since
they are too static), so using ADAFLAGS or BOOT_ADAFLAGS on the command
line is indeed the good mechanism in terms of frequency of needs and
flexibility.
> Since I don't understand really if what I'm saying makes sense, I think
> the best solution is to revert because it is also affecting people that
> use --disable-bootstrap (whom I cannot blame at all).
That would certainly be better than the current situation, although if
you look at Makefile.tpl and EXTRA_GCC_FLAGS, you'll see that we already
apply this treatment to BOOT_ADAFLAGS and this worked as expected,
so why treating ADAFLAGS (using e.g. for cross compilers) differently ?
Arno