Re: [PATCH 1/1] kbuild: record real-prereqs in .cmd files

Luis Augenstein <[email protected]>
Newsgroups org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On 8/18/26 21:51, Nathan Chancellor wrote:
> Sashiko has a comment that this produces different results based on a
> clean versus incremental build:
> 
>    https://sashiko.dev/#/patchset/59032
> 
> I can reproduce this with:
> 
>    $ make -skj"$(nproc)" ARCH=x86_64 mrproper defconfig lib/oid_registry.o
> 
>    $ grep -n oid_registry_data lib/.oid_registry.o.cmd
>    3:make_prereqs_lib/oid_registry.o := lib/oid_registry.c lib/oid_registry_data.c
>    1111:  lib/oid_registry_data.c \
> 
>    $ touch lib/oid_registry.c
> 
>    $ make -skj"$(nproc)" ARCH=x86_64 lib/oid_registry.o
> 
>    $ grep -n oid_registry_data lib/.oid_registry.o.cmd
>    1111:  lib/oid_registry_data.c \
> 
> As this is just metadata for external tools (i.e., it does not get
> consumed by Kbuild again), we could just require them to filter
> duplicates after the fact?

True, some Make prerequisites also appear in deps_*, so the filter
dropped them from make_prereqs_* on incremental builds.

However, we cannot just remove the filter. After the .cmd is included,
$(real-prereqs) contains $(deps_$@), so the whole deps_* list would
show up in make_prereqs_* on a rebuild.

We could move the filter into fixdep and filter based on the new .d 
file, so the overlap is removed already on a clean build.

thanks,
Luis

-- 
Luis Augenstein * [email protected] * +4915225275761
TNG Technology Consulting GmbH, Beta-Str. 13, 85774 Unterföhring
Geschäftsführer: Dr. Robert Dahlke, Thomas Endres, Moritz Prinz
Aufsichtsratsvorsitzender: Henrik Klagges
Sitz: Unterföhring * Registergericht: Amtsgericht München * 
Handelsregisternummer: HRB 135082
OpenPGP_signature.asc (application/pgp-signature, 840 B)
-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEJzBrWn4qHw5a0jAXeVyKys3c+zQFAmqIrZAFAwAAAAAACgkQeVyKys3c+zRU
wQ//eRmJmx6FFIR1X5Jzk7NRLIJJ5wtWB2tNdXKZCKc/MesEHKluw0dN1XK1iFFxMGAwSXBbpKE0
+eX6tUJrkQUgGAHClZgGOLWCO98EGofh/aQ/3RFqcSohbmjClMAEezmLagTswyL0PhI6BtoZuHSE
oxGMy8L+N12ZiEaUn3bLLw1TWuSwCc4F6mX9jFEBxfAChbCk29Slc+att5HSz/JLh7iTOuUP4eZ6
6mFNe3h7zbojTNzPQaxSi9Q8JGnbw9Ad6X7CKdR18YOCC5rLNeRb1VDUoZU7ecbfJm+GG+hDG4Et
d5cmuQXommdDw86FtIrVX7ULHkdrUDmZcNKYHOQpjof7lpjE6CZ5iHoLL/sGRnBbSCcvYNFsVn2J
vRgHO46OzAy7d9DTkEbhvrH82hENBdAgPWAStp/CiM0dw72t+fwdiKemb3ohwnBeWUR+tGtg15US
uO9MY5AizeCbxxFsTOlYJWNkymJantKv7QnuoP5QUOJAnWbEzRHMDvaxsvWp90raCFwU4CslJyRA
Sthtq7YV/96iISLGKSUks5dD38ScU5gfs5j98aNuqcOnXprB+xHQrBrot+VyQcky0D0/cfiwdXyd
GUGwqfHS6vuviy7fEKbiCYKV2L44EhYge1QXWRyVZzNWSZrVvpYmGZ5nS2VJer2SGL5HJ8C/o8CS
PAo=
=/QL+
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.