deliciouslytyped

If I understood you correctly, yes this is how these kinds of functions are supposed to work, you just wrap them around individual points of interest. I've now x-linked this...

Well, I don't see any other way to look at expansions other than doing something like this, and it's nicer than `$(call trace,...)`. With regards to doing it with a...

~~Ok I got some advice on how to maybe reply better.~~ ~~Having this as a feature increases visibility into (deeply) nested code: it allows you to inspect intermediate values without...

Third attempt. I'm learning; How do you figure why this doesn't do anything? ``` all: define _make-dir $1/.dum: $(dir $1) mkdir $(dir $@) touch $(dir $@)/.dum endef define make-dir $(if...

TODO: 1) ``` all: define dirdum $1/.dum endef define _make-dir $(call dirdum,$1): $(call dirdum,$(dir $1)) mkdir $(@D) touch $(@D)/.dum endef define make-dir # $(if $(dir $1),$(call _make-dir,$1),) $(call _make-dir,$1) endef...

I'm currently trying to find a workaround by trying to write a `$(call trace,...)` function that can be inserted in a nested expansion, similar to trace functions in functional programming...

Another possibility might be to - use the gmake guile integration - use GDB with debug symbols enabled, if there is a function corresponding to "return the value of an...

https://github.com/rocky/remake/pull/125 implements the fourth (not explicitly listed previously because I thought it would be a lot harder) option: implementing the trace builtin. However, having the ability to step through expansions...

It's not *critical*, just inconvenient.

This would probably also make it easier to write other frontends? I may be misunderstanding the implications here.