On Wed, Apr 30, 2025 at 01:29:25PM +0100, Richard Sandiford wrote: > Alice Carlotti <alice.carlo...@arm.com> writes: > > On Tue, Apr 29, 2025 at 02:47:21PM +0100, Alice Carlotti wrote: > >> This demonstrates a clear benefit to make the makefile rules automatic. I > >> thought this might be quite tricky, but it turns out to be fairly > >> straightforward. > > > > Actually, it turns out I missed at least one more thing that's needed, so > > the > > first two patches combined don't even build cleanly. The issue is that > > dependencies on generated files need some mechanism to ensure that the > > generated files are available before their dependants are built during a > > clean > > build. This means that I can't just delete the dependency > > > > aarch64-builtins.o: aarch64-builtin-iterators.h > > > > > > Many other generated files are currently specified as prerequisites via the > > rule: > > $(ALL_HOST_OBJS) : | $(generated_files) > > > > I think it would make sense to include the backend generated files into this > > variable. Currently some backend files are included, but this is done using > > the variables TM_H, TM_P_H, TM_D_H and TM_RUST_H variables, which looks > > like a > > misuse of these variables. > > > > The intended meaning/use of the TM_* variables is also unclear. As far as I > > can tell, it looks like they should list the dependencies of the > > corresponding > > files generated by mkconfig, of which the direct includes are added > > automatically, but this isn't quite consistent with the current values in > > t-aarch64. > > Which files are you thinking of when you say that those macros are being > misused, and that the current values in t-aarch64 aren't consistent with > the intended usage? It looks from a quick glance at: > > TM_H += $(srcdir)/config/aarch64/aarch64-fusion-pairs.def \ > $(srcdir)/config/aarch64/aarch64-tuning-flags.def \ > $(srcdir)/config/aarch64/aarch64-option-extensions.def \ > $(srcdir)/config/aarch64/aarch64-cores.def \ > $(srcdir)/config/aarch64/aarch64-isa-modes.def \ > $(srcdir)/config/aarch64/aarch64-arches.def > > that aarch64-fusion-pairs.def and aarch64-tuning-flags.def could be put > in TM_P_H instead of TM_H, since they are included via aarch64-protos.h > but not (apparently) via aarch64.h. But the others look correct.
I think config/arm/aarch-common.h is missing from TM_P_H and bbitmap.h is missing from both. The latter omission was introduced by me last year, but the former has been missing since 2021. (I haven't actually dumped the full value of TM_H to check, so I might have missed some mechanism in the maze of macro definitions. Similarly I think input.h is covered via some chain of macros, but I haven't verified this.) I think it's possible to do some programmatic verification of these macros; I might try that at some point. > > Another related observation is that aarch64-builtin-iterators.h is missing > > from > > MOSTLYCLEANFILES, so it isn't removed in a clean build. It ought to be > > included, and I think it would be good if we could use the same list (or > > mostly > > the same list) of generated files for both the order-only prerequiste rule > > and > > in MOSTLYCLEANFILES. > > I agree that it would be good for the common subset to be specified once > rather than twice. But generated_files includes things generated by > configure, which shouldn't be removed by "make mostlyclean". I couldn't spot any at a glance - do you have a specific example? And why would these need an explicit order dependency? I might be missing some detail of the configure/build flow here. > And MOSTLYCLEANFILES includes .cc files, which shouldn't be > included in the ordering dependency. And I think some targets > use tools to generate installed headers, which also shouldn't be > included in the ordering dependency. > > So I suppose this amounts to a macro that means "generated header files > that are included by host code". I'm not going to suggest a name for that :) > > Richard
