Hi Daniel / Jani. > On Mon, Mar 02, 2020 at 11:22:34AM +0200, Jani Nikula wrote: > > On Sat, 29 Feb 2020, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > > On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: > > >> The header-check infrastructure was dropped again - see: > > >> fcbb8461fd2376ba3782b5b8bd440c929b8e4980 > > > > > > Uh I'm disappoint :-/ > > > > To say the least. I thought it was a good *opt-in* feature for whoever > > wanted it. But the part that got the backlash was applying it to > > absolutely everything under include/. And then it got removed > > altogether. From one extreme to the other. Nuts. > > > > > Adding Jani in case he missed this too. I guess maybe we should > > > resurrect it for drm again (and with a file pattern starting in a > > > .dot). > > > > We have a local implementation in i915/Makefile again. It uses 'find' to > > find the headers which is fine in i915, but the parameters need to be > > adjusted for drm to not be recursive. -maxdepth 1 or something. Also > > need to add another local config option. Sad trombone. > > Splitting this up into two threads. > > Could we extend this to drm headers again too? Sad thrombones indeed, but > at least here we could still the proper fanfares ... Maybe something like > have the Makefile snippet in drivers/gpu and then keep a list of > directories (or file glob patterns probably better) in there that it > should check. > > I really liked this entire idea very much. > > Oh also maybe switch the temp files over to dotfiles, so Linus doesn't get > upset (which really I think is all that Linus expected, but I guess > people just panic and revert). I will try to give it a spin by adding the feature back to kbuild, but without the excessive use. And with dot-files so the run does not disturb. So we avoid different sub-systemes makes there own small solutions. Give me a few weeks - need to land some exciting (not) binding patches for panel/ first. Anyone else up to the task, then I will be happy to review. Sam _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
