On 04/04/2022 13:12, Jakub Jelinek via Gcc-patches wrote:
On Mon, Apr 04, 2022 at 12:32:27PM +0100, Richard Earnshaw via Gcc-patches
wrote:
OK.
Thanks, now committed.
I think we have a similar issue for arm with arm-tune.md and arm-tables.opt.
Perhaps we should adopt a similar approach for those as well.
From what I can see, both arm and c6x suffer from the point 3) in the PR,
i.e. they regenerate files in the source tree regardless of
--enable-maintainer-mode.
Well the read-only tree issue will simply result in a build failure if
the file needs to change - I don't see that as a major issue.
The only risk is if multiple builds are running from the same sources at
the same time and you somehow end up with a race condition.
As for 2), both arm and c6x are ok, but handle it in a different way from
what I did (s-mddeps dependency addition) - they instead set
MD_INCLUDES = long-list-of-*.md-files
s-config s-conditions s-flags s-codes s-constants s-emit s-recog s-preds \
s-opinit s-extract s-peep s-attr s-attrtab s-output: $(MD_INCLUDES)
The MD_INCLUDES variable is overwritten later if mddeps.mk exists and
is included, so the one in t-arm etc. doesn't need to be accurate and can
just contain the files that are generated. The MD_INCLUDES approach
has the disadvantage that people will try to add stuff to it even when
it isn't needed.
rs6000 is the only target that uses MD_INCLUDES beyond arm and c6x, but
in that case the rule to regenerate it is commented out (should that be
enabled for maintainer mode?).
Jakub
Really the long-term solution is to fix these so that both the md
reading machinery and the opt machinery can read generated files from
the build directories, then we wouldn't need to copy anything other than
config files back to the source tree.
R.
