This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fix libcc1 dependencies in toplevel Makefile
- From: Jeff Law <law at redhat dot com>
- To: Alexandre Oliva <oliva at gnu dot org>, Olivier Hainque <hainque at adacore dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Nicolas Roche <roche at adacore dot com>
- Date: Tue, 12 Jun 2018 09:30:23 -0600
- Subject: Re: fix libcc1 dependencies in toplevel Makefile
- References: <AAEA3A59-3545-4EC7-B298-5179483CD129@adacore.com> <orzid0rzk1.fsf@lxoliva.fsfla.org> <F36A0A1A-EC61-46D5-B343-FA839C4DF287@adacore.com> <orpodp5hwg.fsf@lxoliva.fsfla.org> <ortvqj1y63.fsf@lxoliva.fsfla.org> <ory3fku3a1.fsf@lxoliva.fsfla.org>
On 06/11/2018 08:50 PM, Alexandre Oliva wrote:
> So I see two possible ways to go from now:
>
> 1. address the previously-mentioned fragility in the patch I posted, to
> catch all cases of postbootstrap targets and their deps on
> non-postbootstrap targets.
>
>
> 2. revamp the bootstrap/non-bootstrap dependencies, using GNU make
> conditionals rather than configure-time enable/disable-bootstrap, so
> that we can have a different set of dependencies while running the
> bootstrap proper, having non-stage dependencies activated by default
> when any of the all-* targets are named in the command line, and also
> when building post-bootstrap all-host all-target. This might seem to
> bring the problem back, but rather by having the full dependency set,
> we'd avoid the race not by refraining from reentering dirs, but rather
> by having them entered or reentered according to the full dependencies,
> without mixing stage and non-stage dependencies. I'm not yet sure this
> is actually doable, but it seems to me that if it is, it would be more
> robust than what we have now.
Your call. I've wanted the build system revamped for 20+ years, but
it's nontrivial and the most serious problems were addressed as we
continued to pull the runtime bits out of gcc/
Jeff