From: Mark Brown <broonie@kernel.org> To: Masahiro Yamada <masahiroy@kernel.org> Cc: kernel test robot <lkp@intel.com>, llvm@lists.linux.dev, kbuild-all@lists.01.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Michal Marek <michal.lkml@markovi.net>, Nick Desaulniers <ndesaulniers@google.com>, Linux Kbuild mailing list <linux-kbuild@vger.kernel.org> Subject: Re: [broonie-misc:arm64-sysreg-gen 6/9] arch/arm64/include/asm/sysreg.h:125:10: fatal error: 'generated/asm/sysreg.h' file not found Date: Fri, 18 Mar 2022 15:41:33 +0000 [thread overview] Message-ID: <YjSoLTbVBZTNS0tL@sirena.org.uk> (raw) In-Reply-To: <CAK7LNASsiYHK3QW5aOg016_XwD-MmOOcJ6UA=f95BxEZ-p+gSw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1676 bytes --] On Fri, Mar 18, 2022 at 02:15:07PM +0900, Masahiro Yamada wrote: > On Thu, Mar 17, 2022 at 2:05 AM Mark Brown <broonie@kernel.org> wrote: > > but that's only passed to CC (at least for bounds.s) via an > > -I./arch/arm64/include/generated so won't be found with the generated/ > > prefix. While this can be avoided by renaming the header and not > > referencing it with the prefix I do see a bunch of other headers > > throughout the tree being included with an explicit generated/ prefix so > > I'm not sure this is what's supposed to be happening, it does seem like > > a landmine somehow. > Do not add 'generated/' prefix. If that's something you don't want to support there's a bunch of existing explicit usage of generated/ in include statements that need fixing up. > Let's think about this scenario. > First foo.h was hard-coded, but sometime later, > somebody noticed it is better to generate it by scripting. > Why do we need to fix up #include <foo.h> to #include <generated/foo.h> > in all the call sites? > Or do we need to have foo.h to wrap <generaged/foo.h> ? I'm not sure I see a conflict from having both ways to reach the header here and allowing people to do either as appropriate TBH, and indeed we have other cases like uapi where we have both include/ and include/uapi in the search path. > No, users of foo.h do not need to know if it is > a checked-in header of a generated one. The use case I had was for partial conversion where some of the header is pulled out into a generated file with the generated file wrapping things. The users are unaffected, and if the file is completely converted to be generated would continue to be unaffected. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: kbuild-all@lists.01.org Subject: Re: [broonie-misc:arm64-sysreg-gen 6/9] arch/arm64/include/asm/sysreg.h:125:10: fatal error: 'generated/asm/sysreg.h' file not found Date: Fri, 18 Mar 2022 15:41:33 +0000 [thread overview] Message-ID: <YjSoLTbVBZTNS0tL@sirena.org.uk> (raw) In-Reply-To: <CAK7LNASsiYHK3QW5aOg016_XwD-MmOOcJ6UA=f95BxEZ-p+gSw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1712 bytes --] On Fri, Mar 18, 2022 at 02:15:07PM +0900, Masahiro Yamada wrote: > On Thu, Mar 17, 2022 at 2:05 AM Mark Brown <broonie@kernel.org> wrote: > > but that's only passed to CC (at least for bounds.s) via an > > -I./arch/arm64/include/generated so won't be found with the generated/ > > prefix. While this can be avoided by renaming the header and not > > referencing it with the prefix I do see a bunch of other headers > > throughout the tree being included with an explicit generated/ prefix so > > I'm not sure this is what's supposed to be happening, it does seem like > > a landmine somehow. > Do not add 'generated/' prefix. If that's something you don't want to support there's a bunch of existing explicit usage of generated/ in include statements that need fixing up. > Let's think about this scenario. > First foo.h was hard-coded, but sometime later, > somebody noticed it is better to generate it by scripting. > Why do we need to fix up #include <foo.h> to #include <generated/foo.h> > in all the call sites? > Or do we need to have foo.h to wrap <generaged/foo.h> ? I'm not sure I see a conflict from having both ways to reach the header here and allowing people to do either as appropriate TBH, and indeed we have other cases like uapi where we have both include/ and include/uapi in the search path. > No, users of foo.h do not need to know if it is > a checked-in header of a generated one. The use case I had was for partial conversion where some of the header is pulled out into a generated file with the generated file wrapping things. The users are unaffected, and if the file is completely converted to be generated would continue to be unaffected. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-03-18 15:41 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-15 21:56 [broonie-misc:arm64-sysreg-gen 6/9] arch/arm64/include/asm/sysreg.h:125:10: fatal error: 'generated/asm/sysreg.h' file not found kernel test robot 2022-03-16 17:05 ` Mark Brown 2022-03-16 17:05 ` Mark Brown 2022-03-18 5:15 ` Masahiro Yamada 2022-03-18 5:15 ` Masahiro Yamada 2022-03-18 15:41 ` Mark Brown [this message] 2022-03-18 15:41 ` Mark Brown
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=YjSoLTbVBZTNS0tL@sirena.org.uk \ --to=broonie@kernel.org \ --cc=kbuild-all@lists.01.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lkp@intel.com \ --cc=llvm@lists.linux.dev \ --cc=masahiroy@kernel.org \ --cc=michal.lkml@markovi.net \ --cc=ndesaulniers@google.com \ /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: linkBe 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.