On Fri, Jun 27, 2025 at 4:23 AM Paul Smith <psm...@gnu.org> wrote:
>
> On Fri, 2025-06-27 at 04:09 -0800, Britton Kerin wrote:
> > The many answers here show the appetite for finding out about
> > variables:
> > https://stackoverflow.com/questions/16467718/how-to-print-out-a-
> > variable-in-makefile
> >
> > A variety of different approaches are represented there, but none of
> > them cover all situations.
> >
> > I think --debug would be the place for some general solution.
> > Thoughts?
>
> I don't really understand what the ask is here, exactly. Maybe you
Tbh I'm not entirely sure what i want myself. A trace would be simple
to implement, but in a case where a variable is only ever used in the
most vanilla way it might be nice to have my prospective feature just
tell its final value.
> could enumerate (at least some of) "all situations"? By "situations"
> do you mean, locations in the makefile? The $(info ...) function is
I mean when used not immutably on purpose for some reason, as a
target-local variable, etc. It bothers me that the generic-sounding
recipe I mentioned fails badly and misleadingly for both those.
> The $(info ...) function is available everywhere...
Yes, but it requires instrumentation. Usually that's my preferred way
but wanting to know what a var is is so common it might be nice if it
were a little more convenient (i.e. make echo-FOO only rather than
needing an edit). Also I have a situation where instrumentation makes
the repo dirty, which changes other things (yeah I know blech).
> Another option is to use the --print-database (-p) option. Is that
> more what you had in mind?
Close but it's still late only.
This may well be a case where the answer is that the existing stuff is
good enough and nothing more is worthwhile, but I feel like it would
be nice to be able to ask make to tell me the story of FOO, how it
changes or gets shadowed over time, and when it's expanded. --debug
can produce many other things that I've only rarely wanted, but I want
to find out what's going on with variables pretty often.
I got started on this when I happened to notice that if I turn the
originally mentioned rule into a static pattern rule with target list
derived from $(.VARIABLES) like so:
# Vars With Quoted Names. This is required because the automatic variable
# %D and %F show up in $(.VARIABLES) but confuse make when they appear in
# the target list of static pattern rules.
VWQN = $(patsubst \%%, \\\%%, $(.VARIABLES))
# Show the value of a make variable
$(patsubst %, echo-%, $(VWQN)): echo-%: ; @echo '$($*)'
it makes command line completion work on e.g. make echo-<TAB> (and
make echo-F<TAB> etc.), which was really handy! Until I hit a var
that I defined after that point :( And for reasons I don't yet
understand getting the late names of variables via a recursive make
works but doesn't make completion work again (I'll spare you the code
on that unless you're really curious).
Britton
