All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Ingo Schwarze <schwarze@usta.de>
Cc: linux-man@vger.kernel.org
Subject: Re: configure separate from make or not
Date: Sun, 30 Aug 2026 15:17:07 +0200	[thread overview]
Message-ID: <apQq4u6L8i3Ax_DA@devuan> (raw)
In-Reply-To: <apMytOcLd3pecFFc@devuan>

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]

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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2026-08-30 13:17 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 19:21 [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config DJ Delorie
2026-08-06 14:37 ` Alejandro Colomar
2026-08-06 15:33   ` DJ Delorie
2026-08-06 19:14     ` Alejandro Colomar
2026-08-06 20:17       ` DJ Delorie
2026-08-06 20:31         ` Alejandro Colomar
2026-08-06 20:42           ` DJ Delorie
2026-08-07  2:12             ` G. Branden Robinson
2026-08-07  3:29               ` DJ Delorie
2026-08-07  3:49                 ` G. Branden Robinson
2026-08-07  4:01                   ` DJ Delorie
2026-08-07  4:09                     ` G. Branden Robinson
2026-08-23 12:29               ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-23 13:27                 ` G. Branden Robinson
2026-08-23 13:55                   ` Alejandro Colomar
2026-08-23 14:16                     ` G. Branden Robinson
2026-08-23 15:06                       ` Alejandro Colomar
2026-08-23 16:44                         ` G. Branden Robinson
2026-08-23 19:30                           ` Alejandro Colomar
2026-08-23 20:40                             ` G. Branden Robinson
2026-08-23 23:11                               ` Alejandro Colomar
2026-08-24  1:11                                 ` G. Branden Robinson
2026-08-24  2:01                                   ` Using LS/LE Collin Funk
2026-08-24 11:08                                     ` Alejandro Colomar
2026-08-24 11:00                                   ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-23 22:31                             ` autotools, was: Using LS/LE Ingo Schwarze
2026-08-24  0:09                               ` Alejandro Colomar
2026-08-29  4:36                               ` G. Branden Robinson
2026-08-29 11:34                                 ` Ingo Schwarze
2026-08-29 12:51                                   ` Alejandro Colomar
2026-08-29 19:16                                     ` G. Branden Robinson
2026-08-29 21:43                                       ` Alejandro Colomar
     [not found]                             ` <8DE76435-CBDB-42D6-9E0F-9E27291560B6@icloud.com>
2026-08-29  8:42                               ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-29  8:45                                 ` Alejandro Colomar
2026-08-29  8:52                                   ` Alejandro Colomar
2026-08-29  9:02                                     ` Alejandro Colomar
2026-08-29  9:39                               ` Ingo Schwarze
2026-08-29 13:10                                 ` configure separate from make or not (was: Using LS/LE) Alejandro Colomar
2026-08-29 15:31                                   ` configure separate from make or not Ingo Schwarze
2026-08-29 20:49                                     ` Alejandro Colomar
2026-08-30 13:17                                       ` Alejandro Colomar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=apQq4u6L8i3Ax_DA@devuan \
    --to=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=schwarze@usta.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.