Jean-Baptiste Poittevin (10 August 2022 22:19) wrote:
> By using a lot of PHONY targets, I think you're closing a door to one
> make greatest feature : not redoing those things that are already up
> to date.
While that's entirely true of make's "design-basis" use-case, I am
familiar with the mostly-phony style of make-file; it serves, in effect,
as a way of defining a directory-specific set of command aliases, that
need not have anything to do with generating new (local) files.
That may include generating one of a family of reports to stdout, that
gets piped into a mail program to be sent out, without changing anything
on disk; or it may integrate some more traditional use of make, such as
doing a build, with uploading the result to where a client can access
it, sending the client an e-mail about that and logging that this has
happened in a support database via REST calls. Or it could be used to
initiate back-ups of parts of a system to a tape device (after taking
care to insert a suitably labelled tape in its drive). Even though
these are, in some sense, creating files from inputs, the generated "file"
(in someone's in-box, in the support database, on the tape) is external
to the system on which make can query time-stamps.
This enables a work-flow where, to perform a set of routine tasks, I
just cd to a directory set up to facilitate those tasks (it likely has
symlinks to assorted resources to be consulted as part of them) and make
a target to initiate some complex command or sequence of commands.
Having several targets in the make-file can make this map several
related tasks to handy mnemonic names, saving the need to remember,
reinvent or look up potentially long and complex command-lines.
For example: I could have one such directory for each of several
clients; each Makefile sets some client-specific parameters and imports
suitable make-files from a common store, while its directory contains
symlinks to the resources needed for tasks related to those clients.
This can then make various processes involving interaction with clients
(and suitable logging to accounting, support and other databases on
other hosts) uniform (thereby greatly reducing the scope for mistakes).
This might more traditionally be done by writing a script, with various
options to select between the related tasks my directory exists to
support doing, but make is actually a very good way to structure some
such scripts, particularly when some of the tasks need others to be
performed first. Naturally, if some of the tasks need certain files to
also be up to date before they are run, this also integrates nicely with
make's design-basis use-case.
It is some decades since I've had tasks for which I used this approach,
so I forget the particular use-cases to which I applied it, and it
sounds like Katherine has a more involved example of it than I've ever
used it for, but once you let go of the assumption that make is only
used to turn (local) source files into generated (local) files, there
are some interesting ways that make can serve as a very handy scripting
language. It's just a bit tedious to have to mark a lot of rules as
phony.
Eddy.
