bfd+ld: when / whether to generate .c files
authorJan Beulich <jbeulich@suse.com>
Tue, 4 Apr 2023 06:50:18 +0000 (08:50 +0200)
committerJan Beulich <jbeulich@suse.com>
Tue, 4 Apr 2023 06:50:18 +0000 (08:50 +0200)
commit02d44d76584e4d483fe0fc677c12066ec23d67f4
tree17973e7043745217bd770cf83b9795097a166858
parent19cacf672930cee20feaf1f3468e3d5ac3099ffd
bfd+ld: when / whether to generate .c files

Having been irritated by seeing bfd/elf{32,64}-aarch64.c to be re-
generated in x86-only builds, I came across 769a27ade588 ("Re: bfd
BLD-POTFILES.in dependencies"). I think this went slightly too far, as
outside of maintainer mode dependencies will cause the subset of files
to be (re-)generated which are actually needed for the build.
Generating them all is only needed when wanting to update certain files
under bfd/po/, i.e. in maintainer mode.

In the course of looking around in an attempt to try to understand how
things are meant to work, I further noticed that ld has got things
slightly wrong too: BLD-POTFILES.in depending on $(BLD_POTFILES) isn't
quite right (the output doesn't change when any of the enumerated files
changes; it's the mere presence which matters); like in bfd it looks
like we would better extend BUILT_SOURCES accordingly.

Furthermore it became apparent that ld fails to enumerate the .c files
generated from the .l and .y ones. While in their absence it was benign
whether translatable strings in the source files were actually marked as
such, this now becomes relevant. Mark respective strings at the same
time, but skipping ones which look to be of interest for debugging
purposes only (e.g. such used by printf() enclosed in #ifdef TRACE).
bfd/Makefile.am
bfd/Makefile.in
ld/Makefile.am
ld/Makefile.in
ld/deffilep.y
ld/ldgram.y
ld/ldlex.l