One of the maxims of redo that goes back to the original Bernstein design is 'honest dependencies'. This applies to compiler/linker/assembler/archiver flags.
Compiler flags are first class parts of a build system with redo.
Very simply:
They are stored in files, that are generated by .do programs that auto‐detect the system's available compiler (and tailor what flags to use for it), and that are read and declared as redo-ifchange dependencies by the .do programs (or their ancillary helper tools) that compile/link/assemble/archive things.
To put this into concrete terms:
A system that linked a lot of binary programs from object files, themselves compiled from source code, might have .do programs that made use of helper tools named compile and link, rather than repeat the instructions to compile and to link object files in each .do program.
# In wibble.do:
objects="wibble.o"
redo-ifchange link ${objects}
./link wibble ${objects} …
# In default.o.do:
redo-ifchange compile ${main}.cxx
./compile ${main}.cxx …
compile and link read the compiler tool, linker tool, compiler flags, and linker flags from files; which are named (say) cxx, ld, cxxflags, and ldflags.
They declare dependence upon these files ever changing with redo-ifchange.
Changing the compiler name or flags thus causes compile to be run again; and likewise the linker name and flags and link.
# In the compile helper:
redo-ifchange cxx cxxflags
read -r cxx < cxx
read -r cxxflags < cxxflags
${cxx} ${cxxflags} …
# In the link helper:
redo-ifchange cxx ldflags
read -r cxx < cxx
read -r ldflags < ldflags
${cxx} ${ldlags} …
(There is an important side note to observe here.
redo-ifchange et al. do not have to be invoked directly within a .do program.
They can be invoked by anything that the .do program runs, too.)
Things could stop there, requiring the person building the binary programs to manually write the contents of the cxx, ld, cxxflags, and ldflags files to suit the host system.
Or these, too, could be targets; the outputs of cxx.do, ld.do, cxxflags.do, and ldflags.do programs.
The latter could be .do programs smart enough to probe for various known compiler and linkers, and emit the right compiler and linker names and flags, that apply on the particular host system.
So the first built step on a fresh, clean, system is to auto‐configure the build system for whatever compiler is locally installed.
A step even further is to use command -v to locate the compiler tool name by its full path and declare a dependency on its existence from cxx.do with redo-ifdelete.
Replacing the operating system's compiler then causes the build system to auto‐reconfigure itself for whatever different compiler is now available.