Hi Ingo,

> Date: 2026-08-29 22:49:08+0200
> From: Alejandro Colomar <alx@kernel.org>
>
[...]
>
> The main thing I run code for in the makefiles is for listing all the
> source files.  Here's an example:
> 
> 	$ grepc -xmk -tv -n MANPAGES share/mk/
> 	share/mk/src/man.mk:20:MANPAGES ::= $(shell $(FIND) $(MANDIR)/* -type f \
> 			| $(GREP) -E '$(MANEXT)' \
> 			| $(SORTMAN) \
> 			| $(SED) 's,:,\\:,g')
> 
> I know you prefer to list them manually, but I like this little bit
> of magic (it's not that magic, since it's written in the code, but
> admittedly, if you're not used to this build system, it's hard to
> expect it).

BTW, the git repository is tracking 3387 files (at the moment, and
growing), and thus the distribution tarball contains that many files.
Given this amount of files, I find it more maintainable using scripts
instead of hard-coded lists.  I could have a hard-coded list, and
regularly diff it with the output of find(1), but I prefer using find(1)
directly in the makefiles.  Also, I wouldn't want to have 80k of
Makefile text that is the output of a command:

	$ git ls-files | wc -c
	80511

We already have quite heavy makefiles, at around 100k, and that would
duplicate their size.

[...]
> The thing is, we have 1.5k non-link pages, and we use absolute paths
> in most variables.  Thus, each variable can hold around 100kB for the
> paths:
> 
> 	$ find man/ -type f | xargs grep -l '^\.TH' | xargs realpath | wc -c
> 	106833
> 
> 'make help-list-targets' lists 119 .PHONY targets, of which most require
> at least one variable for holding the actual file targets.  A simple
> multiplication and rounding says there's 100x100k = 10M in these path
> variables.  Then 25 MB sounds not far from that.
> 
> I think I might be able to optimize this down by using relative paths.
> I might be able to optimize this a bit further by using suffix rules
> as much as possible, instead of listing all targets in the rules again.
> But there's a hard floor.  It should be hard to go much below current
> size, at least without reducing targets.

Self-correction: we're not using absolute paths; they're relative.
It seems I had already implemented this optimization, and I didn't
remember.  Anyway, relative paths don't change much.  The best gain
would come from using suffix rules, which would save a few variables
entirely.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>