mbox series

[GIT,PULL] Kbuild updates for v6.3-rc1

Message ID CAK7LNATJ-3JQ0QQGQ5R+R8aBJEq-tmBL8iBZrbM_4t0zeoYTaw@mail.gmail.com (mailing list archive)
State New, archived
Headers show
Series [GIT,PULL] Kbuild updates for v6.3-rc1 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-v6.3

Message

Masahiro Yamada Feb. 26, 2023, 4:33 p.m. UTC
Hello Linus,

Please pull Kbuild updates for v6.3-rc1.

Thank you






The following changes since commit 2241ab53cbb5cdb08a6b2d4688feb13971058f65:

  Linux 6.2-rc5 (2023-01-21 16:27:01 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v6.3

for you to fetch changes up to 7adf14d8aca1ea53bf9ccf8463809c82adb8c23a:

  kbuild: rpm-pkg: remove unneeded KERNELRELEASE from
modules/headers_install (2023-02-26 16:54:12 +0900)

----------------------------------------------------------------
Kbuild updates for v6.3

 - Change V=1 option to print both short log and full command log.

 - Allow V=1 and V=2 to be combined as V=12.

 - Make W=1 detect wrong .gitignore files.

 - Tree-wide cleanups for unused command line arguments passed to Clang.

 - Stop using -Qunused-arguments with Clang.

 - Make scripts/setlocalversion handle only correct release tags instead
   of any arbitrary annotated tag.

 - Create Debian and RPM source packages without cleaning the source tree.

 - Various cleanups for packaging.

----------------------------------------------------------------
Bastian Germann (1):
      builddeb: clean generated package content

Carlos Llamas (1):
      kbuild: fix trivial typo in comment

Jani Nikula (6):
      MAINTAINERS: fix kbuild repo branch
      docs/kbuild/makefiles: fix header underline
      docs/kbuild/makefiles: throw out the local table of contents
      docs/kbuild/makefiles: drop section numbering, use references
      docs/kbuild/makefiles: clean up indentation and whitespace
      docs/kbuild/makefiles: unify quoting

Masahiro Yamada (46):
      kbuild: refactor silent mode detection
      kbuild: print short log in addition to the whole command with V=1
      kbuild: do not print extra logs for V=2
      kbuild: allow to combine multiple V= levels
      kbuild: drop V=0 support
      kbuild: clean up stale file removal
      .gitignore: update the command to check tracked files being ignored
      kbuild: make W=1 warn files that are tracked but ignored by git
      kbuild: rename cmd_$@ to savedcmd_$@ in *.cmd files
      kbuild: add more comments for KBUILD_NOCMDDEP=1
      kbuild: unify cmd_dt_S_dtb and cmd_dt_S_dtbo
      kbuild: refactor host*_flags
      kbuild: specify output names separately for each emission type from rustc
      fixdep: parse Makefile more correctly to handle comments etc.
      kbuild: remove sed commands after rustc rules
      fixdep: refactor hash table lookup
      fixdep: avoid parsing the same file over again
      fixdep: do not parse *.rlib, *.rmeta, *.so
      kbuild: rust: move rust/target.json to scripts/
      kbuild: replace $(dot-target).tmp in filechk with $(tmp-target)
      scripts: handle BrokenPipeError for python scripts
      scripts: remove bin2c
      kbuild: do not put .scmversion into the source tarball
      setlocalversion: simplify the construction of the short version
      setlocalversion: make indentation shallower
      setlocalversion: absorb $(KERNELVERSION)
      kbuild: save overridden KERNELRELEASE in include/config/kernel.release
      kbuild: deb-pkg: add --source-option=-sP
      kbuild: do not automatically add -w option to modpost
      kbuild: remove --include-dir MAKEFLAG from top Makefile
      .gitignore: ignore *.cover and *.mbx
      setlocalversion: clean up the construction of version output
      setlocalversion: use only the correct release tag for git-describe
      kbuild: add a tool to list files ignored by git
      kbuild: deb-pkg: create source package without cleaning
      kbuild: rpm-pkg: build binary packages from source rpm
      kbuild: srcrpm-pkg: create source package without cleaning
      kbuild: deb-pkg: hide KDEB_SOURCENAME from Makefile
      kbuild: deb-pkg: make .orig tarball a hard link if possible
      kbuild: deb-pkg: switch over to source format 3.0 (quilt)
      kbuild: make perf-tar*-src-pkg work without relying on git
      kbuild: tar-pkg: use tar rules in scripts/Makefile.package
      kbuild: deb-pkg: fix binary-arch and clean in debian/rules
      kbuild: deb-pkg: improve the usability of source package
      .gitattributes: use 'dts' diff driver for *.dtso files
      kbuild: rpm-pkg: remove unneeded KERNELRELEASE from
modules/headers_install

Nathan Chancellor (13):
      MIPS: Always use -Wa,-msoft-float and eliminate GAS_HAS_SET_HARDFLOAT
      MIPS: Prefer cc-option for additions to cflags
      powerpc: Remove linker flag from KBUILD_AFLAGS
      powerpc/vdso: Remove unused '-s' flag from ASFLAGS
      powerpc/vdso: Improve linker flags
      powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o
with clang
      s390/vdso: Drop unused '-s' flag from KBUILD_AFLAGS_64
      s390/vdso: Drop '-shared' from KBUILD_CFLAGS_64
      s390/purgatory: Remove unused '-MD' and unnecessary '-c' flags
      drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang
      kbuild: Turn a couple more of clang's unused option warnings into errors
      kbuild: Stop using '-Qunused-arguments' with clang
      powerpc/vdso: Filter clang's auto var init zero enabler when linking

Nick Desaulniers (3):
      x86/boot/compressed: prefer cc-option for CFLAGS additions
      kbuild: Update assembler calls to use proper flags and language target
      Documentation/llvm: add Chimera Linux, Google and Meta datacenters

Sangmoon Kim (1):
      docs: kbuild: remove description of KBUILD_LDS_MODULE

Sven Joachim (1):
      builddeb: Consolidate consecutive chmod calls into one

Thomas Weißschuh (2):
      kbuild: also delete temporary directories
      kheaders: use standard naming for the temporary directory

 .gitattributes                              |    8 +-
 .gitignore                                  |    4 +-
 Documentation/Makefile                      |    2 +-
 Documentation/dontdiff                      |    1 -
 Documentation/kbuild/llvm.rst               |   15 +-
 Documentation/kbuild/makefiles.rst          | 2144
+++++++++++++++++------------------
 MAINTAINERS                                 |    2 +-
 Makefile                                    |   93 +-
 arch/arm/mach-s3c/Makefile                  |    4 +-
 arch/ia64/kernel/Makefile                   |    2 +-
 arch/mips/Kbuild                            |    2 +-
 arch/mips/Makefile                          |   13 +-
 arch/mips/Makefile.postlink                 |    2 +-
 arch/mips/include/asm/asmmacro-32.h         |    4 +-
 arch/mips/include/asm/asmmacro.h            |   42 +-
 arch/mips/include/asm/fpregdef.h            |   14 -
 arch/mips/include/asm/mipsregs.h            |   20 +-
 arch/mips/kernel/genex.S                    |    2 +-
 arch/mips/kernel/r2300_fpu.S                |    4 +-
 arch/mips/kernel/r4k_fpu.S                  |   12 +-
 arch/mips/kvm/fpu.S                         |    6 +-
 arch/mips/loongson2ef/Platform              |    2 +-
 arch/powerpc/Makefile                       |    2 +-
 arch/powerpc/Makefile.postlink              |    2 +-
 arch/powerpc/kernel/prom_init_check.sh      |    9 +-
 arch/powerpc/kernel/vdso/Makefile           |   27 +-
 arch/s390/kernel/vdso64/Makefile            |    4 +-
 arch/s390/purgatory/Makefile                |    2 +-
 arch/sh/boot/compressed/Makefile            |    7 -
 arch/um/drivers/Makefile                    |    2 +-
 arch/um/kernel/Makefile                     |    2 +-
 arch/um/kernel/skas/Makefile                |    2 +-
 arch/um/os-Linux/Makefile                   |    2 +-
 arch/um/os-Linux/drivers/Makefile           |    2 +-
 arch/um/os-Linux/skas/Makefile              |    2 +-
 arch/x86/Makefile.um                        |    2 +-
 arch/x86/boot/compressed/Makefile           |    2 +-
 arch/x86/tools/Makefile                     |    2 +-
 arch/x86/um/Makefile                        |    2 +-
 arch/x86/um/os-Linux/Makefile               |    2 +-
 certs/extract-cert.c                        |    9 +-
 drivers/Makefile                            |    5 +
 drivers/gpu/drm/amd/display/dc/dml/Makefile |    3 +-
 fs/hostfs/Makefile                          |    2 +-
 init/Kconfig                                |    4 -
 kernel/gen_kheaders.sh                      |    2 +-
 rust/.gitignore                             |    1 -
 rust/Makefile                               |   27 +-
 scripts/.gitignore                          |    3 +-
 scripts/Kbuild.include                      |   50 +-
 scripts/Kconfig.include                     |    2 +-
 scripts/Makefile                            |   11 +-
 scripts/Makefile.build                      |   26 +-
 scripts/Makefile.clang                      |    2 +
 scripts/Makefile.compiler                   |    8 +-
 scripts/Makefile.host                       |   24 +-
 scripts/Makefile.lib                        |   45 +-
 scripts/Makefile.modfinal                   |    2 +-
 scripts/Makefile.modpost                    |    8 +-
 scripts/Makefile.package                    |  241 ++--
 scripts/as-version.sh                       |    2 +-
 scripts/asn1_compiler.c                     |    4 +-
 scripts/basic/fixdep.c                      |  238 ++--
 scripts/bin2c.c                             |   36 -
 scripts/checkkconfigsymbols.py              |   13 +-
 scripts/clang-tools/gen_compile_commands.py |    2 +-
 scripts/clang-tools/run-clang-tools.py      |   21 +-
 scripts/diffconfig                          |   16 +-
 scripts/kernel-doc                          |    4 +-
 scripts/list-gitignored.c                   | 1057 +++++++++++++++++
 scripts/misc-check                          |   19 +
 scripts/package/builddeb                    |    8 +-
 scripts/package/buildtar                    |   52 +-
 scripts/package/deb-build-option            |   16 +
 scripts/package/mkdebian                    |   40 +-
 scripts/package/mkspec                      |   12 +-
 scripts/remove-stale-files                  |   30 +-
 scripts/setlocalversion                     |  132 +--
 scripts/tags.sh                             |    2 +-
 79 files changed, 2874 insertions(+), 1778 deletions(-)
 delete mode 100644 scripts/bin2c.c
 create mode 100644 scripts/list-gitignored.c
 create mode 100755 scripts/misc-check
 create mode 100755 scripts/package/deb-build-option

Comments

Linus Torvalds Feb. 26, 2023, 6:58 p.m. UTC | #1
On Sun, Feb 26, 2023 at 8:34 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Masahiro Yamada (46):
>       kbuild: add a tool to list files ignored by git
>       kbuild: make perf-tar*-src-pkg work without relying on git

I've pulled this, but I really object to these kinds of silly games.

That whole list-gitignored thing should go away, and silly
work-arounds for "I don't use git" should likewise just be killed.

There's absolutely _zero_ exzcuse for making our build tools more
complicated for bad reasons. The "I don't have git" may have been a
reason a decade ago. It's *not* a valid reason today.

People who insist on using quilt etc should just realize that then
they don't get the featrues that git offers.

You can't have your cake and eat it too.

I do *not* want to see git functionality basically duplicated in some
kernel C helper script just because somebody can't be bothered to just
use git.

              Linus
pr-tracker-bot@kernel.org Feb. 26, 2023, 8:40 p.m. UTC | #2
The pull request you sent on Mon, 27 Feb 2023 01:33:25 +0900:

> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-v6.3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/498a1cf902c31c3af398082d65cf150b33b367e6

Thank you!
Masahiro Yamada Feb. 27, 2023, 10:09 a.m. UTC | #3
Hi Linus,


On Mon, Feb 27, 2023 at 3:58 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, Feb 26, 2023 at 8:34 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > Masahiro Yamada (46):
> >       kbuild: add a tool to list files ignored by git
> >       kbuild: make perf-tar*-src-pkg work without relying on git
>
> I've pulled this, but I really object to these kinds of silly games.
>
> That whole list-gitignored thing should go away, and silly
> work-arounds for "I don't use git" should likewise just be killed.
>
> There's absolutely _zero_ exzcuse for making our build tools more
> complicated for bad reasons. The "I don't have git" may have been a
> reason a decade ago. It's *not* a valid reason today.


We can say "You must install git on your machine", but IMHO
"the kernel must be managed by git" is a too strong assumption
because snapshots are delivers as a tarball (e.g. https://www.kernel.org/)
I could be wrong, but that is my intent (as in the commit description).


>
> People who insist on using quilt etc should just realize that then
> they don't get the featrues that git offers.
>
> You can't have your cake and eat it too.
>
> I do *not* want to see git functionality basically duplicated in some
> kernel C helper script just because somebody can't be bothered to just
> use git.
>
>               Linus


If tar's --exclude-vcs-ignores option had worked correctly,
I would not have written such a gitignore parser by myself.
When tar implements --exclude-vcs-ignores correctly,
I am happy to remove this silly tool.
(In turn, tar will end up with a similar gitignore parser as git, though.)





--
Best Regards
Masahiro Yamada
Linus Torvalds Feb. 27, 2023, 5:08 p.m. UTC | #4
On Mon, Feb 27, 2023 at 2:10 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> If tar's --exclude-vcs-ignores option had worked correctly,
> I would not have written such a gitignore parser by myself.

But that thing is *WRONG*.

Seriously. It's fundamentally wrong.

The thing is, you don't even seem to understand how gitignores work.

A gitignore pattern doesn't actually mean "this path does not exist in the VCS".

It means "git will ignore this path for unknown files".

And that's a *big* difference.

That "for unknown files" means that *known* files can still match the pattern.

And that is actually a perfectly valid pattern, and is very much by
design. You can say "ignore unknown *.o files", but still actually add
one explicitly to a git repository, if there is some special case.
There's nothing wrong with it.

But the way you have done things, it now is actively wrong.

We are *not* adding complexity for no good reason, particularly when
said complexity is fundamentally *broken*.

Yes, we export the kernel as a tar-file. But that's for people who
just don't want to deal with the full deal, and even that is partly
for legacy reasons that aren't necessarily all that true any more.

I suspect that by now, there are probably _more_ people used to git
than there are people who are still used to the "tar-files and
patches" workflow.

So here's the simple rule: if the packaging people can't be bothered
to use "gti archive" to make their packages, then they had better just
do a "make clean" first (or, better yet, do "git clean -dqfx" to
really clean up, because "make clean" isn't 100% reliable either).

We don't add more broken infrastructure to deal with broken workflows.
Just do the right thing.

Or if package managers want to do their own thing, then they can damn
well do it in their own broken systems, not adding a completely broken
script to the kernel.

                Linus
Linus Torvalds Feb. 27, 2023, 5:25 p.m. UTC | #5
On Mon, Feb 27, 2023 at 9:08 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So here's the simple rule: if the packaging people can't be bothered
> to use "gti archive" to make their packages, then they had better just
> do a "make clean" first (or, better yet, do "git clean -dqfx" to
> really clean up, because "make clean" isn't 100% reliable either).
>
> We don't add more broken infrastructure to deal with broken workflows.
> Just do the right thing.

Note: I'm perfectly happy to just revert this, but if I have to do it,
then pretty much _all_ the packaging changes get reverted, because I'm
not going to be able to figure out which parts don't rely on the new
broken script.

So I'd rather take a more directed revert from you. Or, better yet,
just a rewrite to do the right thing (ie "git archive").

Because really - any distro packager had better have the git tree.

                   Linus
Masahiro Yamada Feb. 28, 2023, 4:19 p.m. UTC | #6
On Tue, Feb 28, 2023 at 2:08 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Feb 27, 2023 at 2:10 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > If tar's --exclude-vcs-ignores option had worked correctly,
> > I would not have written such a gitignore parser by myself.
>
> But that thing is *WRONG*.
>
> Seriously. It's fundamentally wrong.
>
> The thing is, you don't even seem to understand how gitignores work.
>
> A gitignore pattern doesn't actually mean "this path does not exist in the VCS".
>
> It means "git will ignore this path for unknown files".
>
> And that's a *big* difference.


Of course, I know this difference.

I wrote it in the commit description of
5c3d1d0abb12a6915d0f43233837053945621a89

Please read it closely.





We are talking past each other due to the disagreement
about what the source code means.

You think "what is committed in the VCS is the source code"
in other words, files in "HEAD" are sources.



I think "what exists in the source tree is the source code"
that is, files in the "working tree" are sources.

Of course, the working tree contains a lot of build artifacts, hence
the list-gitignored tool excludes them.




>
> That "for unknown files" means that *known* files can still match the pattern.

Yes,

'git ls-files -i -c --exclude-per-directory=.gitignore'

lists those files. None of them is needed for building the kernel,
and if we want, it is easy to fix .gitignore files.


>
> And that is actually a perfectly valid pattern, and is very much by
> design. You can say "ignore unknown *.o files", but still actually add
> one explicitly to a git repository, if there is some special case.
> There's nothing wrong with it.
>
> But the way you have done things, it now is actively wrong.
>
> We are *not* adding complexity for no good reason, particularly when
> said complexity is fundamentally *broken*.
>
> Yes, we export the kernel as a tar-file. But that's for people who
> just don't want to deal with the full deal, and even that is partly
> for legacy reasons that aren't necessarily all that true any more.
>
> I suspect that by now, there are probably _more_ people used to git
> than there are people who are still used to the "tar-files and
> patches" workflow.

I do not know.
We are discussing from upstream developers' point of view,
not from packagers' point of view.



>
> So here's the simple rule: if the packaging people can't be bothered
> to use "gti archive" to make their packages, then they had better just
> do a "make clean" first (or, better yet, do "git clean -dqfx" to
> really clean up, because "make clean" isn't 100% reliable either).
>
> We don't add more broken infrastructure to deal with broken workflows.
> Just do the right thing.
>
> Or if package managers want to do their own thing, then they can damn
> well do it in their own broken systems, not adding a completely broken
> script to the kernel.

Fair enough.


>
>                 Linus


--
Best Regards
Masahiro Yamada
Masahiro Yamada Feb. 28, 2023, 4:21 p.m. UTC | #7
On Tue, Feb 28, 2023 at 2:26 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Feb 27, 2023 at 9:08 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So here's the simple rule: if the packaging people can't be bothered
> > to use "gti archive" to make their packages, then they had better just
> > do a "make clean" first (or, better yet, do "git clean -dqfx" to
> > really clean up, because "make clean" isn't 100% reliable either).
> >
> > We don't add more broken infrastructure to deal with broken workflows.
> > Just do the right thing.
>
> Note: I'm perfectly happy to just revert this, but if I have to do it,
> then pretty much _all_ the packaging changes get reverted, because I'm
> not going to be able to figure out which parts don't rely on the new
> broken script.
>
> So I'd rather take a more directed revert from you. Or, better yet,
> just a rewrite to do the right thing (ie "git archive").
>
> Because really - any distro packager had better have the git tree.

OK, let's go this way.

Please give me a few days.





>
>                    Linus