Message ID | CAK7LNAT-D68xMFrE-D_F-2y+iZt45+8iLF9dmTyO8YwUX-bTqA@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] More Kbuild updates for v5.4-rc1 | expand |
On Sat, Sep 28, 2019 at 11:41 AM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > Please pull some more updates for v5.4-rc1 I pulled this, but I'm not sure if I'm going to keep it. There's thousands of lines of changes because of the header-test-y thing, and I'm honestly considering just getting rid of that thing entirely. It has no actual upside that I can tell, and it's extremely annoying. It pollutes the tree with hundreds of *.h.s files, which messes up filename completion, and just generally is ugly and annoying. So I've unpulled for now, and I'm not sure I want to pull more noise for this mis-feature. Linus
Hi Linus, On Sun, Sep 29, 2019 at 11:57 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Sat, Sep 28, 2019 at 11:41 AM Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: > > > > Please pull some more updates for v5.4-rc1 > > I pulled this, but I'm not sure if I'm going to keep it. > > There's thousands of lines of changes because of the header-test-y > thing, and I'm honestly considering just getting rid of that thing > entirely. > > It has no actual upside that I can tell, and it's extremely annoying. > It pollutes the tree with hundreds of *.h.s files, which messes up > filename completion, and just generally is ugly and annoying. > > So I've unpulled for now, and I'm not sure I want to pull more noise > for this mis-feature. > > Linus The concept of header test is to make sure every header is self-contained, so that headers can be included in either #include <linux/foo.h> #include <linux/bar.h> or #include <linux/bar.h> #include <linux/foo.h> Of course, you can argue that it is addressing hypothetical issues "what if the include directives are arranged in this order?", that nobody has been hit before. If this test is just annoying, shall we remove the 'header-test-y' syntax and include/Kbuild entirely? But, at least, I want to continue compile-testing uapi headers that are exported to user-space. This is useful to detect a broken uapi header that is never be able to be compiled in user-space. For example, https://lkml.org/lkml/2019/6/19/104 So, I'd like to keep usr/include/Makefile at least.
On Sat, Sep 28, 2019 at 9:00 PM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > The concept of header test is to make sure every header > is self-contained, Yes, I realize. But at the same time the filenames it creates are very annoying and clutter up the tree, and I'm not sure we really want that in the first place. The thing _I_ would want is actually a lot less includes, and a lot more streamlined, just for better build times. I sometimes get a small pull, and wonder why the *whole* tree recompiles, and realize that it's due to some really obscure header file that just gets included "in case". So I'd like us to be stricter about header files another way entirely, and I'm not sure that header files should need to be completely independent. > Of course, you can argue that it is addressing hypothetical issues > "what if the include directives are arranged in this order?", > that nobody has been hit before. Well, I think people hit it all the time but just add the right header file when some build fails. In a perfect world, we'd have something that understands what symbols get declared in each header file, and what symbols each header file needs, and have a SAT solver for this that actually also understands about different configurations and architectures. And actually minimize the headers, and have a tool that warns when you have unnecessary ones - or are lacking some. Yeah, it's probably too complex to be worth the pain, but it would be lovely. > But, at least, I want to continue compile-testing > uapi headers that are exported to user-space. I think the uapi headers have a much stronger case for being self-sufficient, but even there I'd really prefer some other model than "*.h.s". We have the dot-files for dependencies and for tracking the command that was used to generate them, I'd much rather have that. At least then we wouldn't uglify the directory structure. Yea, I realize that some people "solve" that problem by just not building in the source-tree at all, but I find that annoying too. Linus