This RFC series shows the steps that I believe are relevant to using automatic make depencies, and optionally automatic make rules, in the aarch64 backend. I believe the same steps and caveats would apply to other backends as well.
This builds upon the work by Tom Tromey in 2013 (see e.g. [1]), which in turn was a resurrection of Tom's earlier attempt in 2008 ([2]). Tom's work only addressed dependencies in the middle end and front ends, and left the backends unchanged. I think it would be beneficial to convert the backend makefile rules as well, to avoid the burden of updating the dependencies manually or the confusion that arises when that is forgotten. In the past couple of years I have: - Discovered a missing dependency that lead to confusing out-of-sync enum values in driver-aarch64.cc (fixed in 943fd92254); - Forgotten to update dependencies in my own patch in February, and only rembering this once my patch was approved and I was about to push it (pushed as 7135570043); - Discovered a typo in another existing dependency variable (REG_H instead of REGS_H, fixed in the above commit). 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. However, there are a few caveats to consider. This series is split into three patches to show the logical steps involved. It may be appropriate to merge these as a squashed patch, or to merge them separately with a significant time gap, in order to avoid issues that can arise with some of the intermediate step. - Patch 1 uses $(COMPILE) and $(POSTCOMPILE) to ensure that all rules *output* and *use* automatic dependencies. - Patch 2 removes explicit dependencies. - Patch 3 modifies the object file locations to enable use of the default .cc.o rule. I think patches 1+2 are definitely desirable. Patch 3 is a little more invasive, and less important (because a missing rule is a much more obvious error than a missing dependency). I am therefore posting it as a hacky RFC, and will implement proper plumbing as required if using the default rule is desirable. Merging both patches 1 and 2 requires measures to ensure that we do not lose necessary dependency information when doing incremental builds. The problem arises because patch 2 lacks most of the required dependency information until the object file has been rebuilt with the compile command from patch 1. There are two ways I can see to avoid this issue: Option 1: Merge patch 1, wait for .cc files to be changed, and then merge patch 2. This would ensure that any incremental build that lacked both automatic and explicit dependencies would rebuild the affect object files anyway, due to the explicit dependency on the changed .cc file. Almost every file has its copyright header changed in the new year, so this would be satified by merging patch 1 this year, and merging patch 2 in January. Option 2: Merge patches 2+3 at the same time - this would change the location of the affected object files, ensuring they are rebuilt without depending upon the automatic dependency files. These considerations apply to all backends, so it might be worth making taking the same approach for all backends. What do you think? [1] https://gcc.gnu.org/pipermail/gcc-patches/2013-September/370648.html [2] https://gcc.gnu.org/legacy-ml/gcc-patches/2008-03/msg00503.html
