Alice Carlotti <alice.carlo...@arm.com> writes: > 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.
Ah, ok, so it was more about missing entries? > (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. I was thinking of config.h, tm.h and tm_p.h, which are removed by clean (of course!) but not by mostlyclean. I'm not 100% sure why they're in the ordering rule, but perhaps it's in case config.status is rerun due to an update to the configuration files. Thanks, Richard
