From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753434AbcHPKxH (ORCPT ); Tue, 16 Aug 2016 06:53:07 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:50304 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753229AbcHPKxG (ORCPT ); Tue, 16 Aug 2016 06:53:06 -0400 Date: Tue, 16 Aug 2016 12:53:15 +0200 From: Greg Kroah-Hartman To: Joe Perches Cc: Oleg Drokin , devel@driverdev.osuosl.org, Andreas Dilger , linux-kernel@vger.kernel.org, lustre-devel@lists.lustre.org Subject: Re: [PATCH 1/2] staging: lustre: Add include path to Makefile Message-ID: <20160816105315.GE28337@kroah.com> References: <5f9f49c1e0caeb3b9ee0656b6d922dbaf52a15b7.1471289489.git.joe@perches.com> <20160815210420.GA30864@kroah.com> <1471295658.4075.117.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1471295658.4075.117.camel@perches.com> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2016 at 02:14:18PM -0700, Joe Perches wrote: > On Mon, 2016-08-15 at 23:04 +0200, Greg Kroah-Hartman wrote: > > On Mon, Aug 15, 2016 at 12:33:23PM -0700, Joe Perches wrote: > > > Start to rationalize include paths in source code files. > [] > > > diff --git a/drivers/staging/lustre/Makefile b/drivers/staging/lustre/Makefile > [] > > > @@ -1,2 +1,5 @@ > > > +subdir-ccflags-y += -I$(srctree)/drivers/staging/lustre/include/ > > > +subdir-ccflags-y += -I$(srctree)/drivers/staging/lustre/lustre/include/ > > > + > > >  obj-$(CONFIG_LNET) += lnet/ > > >  obj-$(CONFIG_LUSTRE_FS) += lustre/ > > This is good, but does this break the subdir make command: > > make M=drivers/staging/lustre/foo_dir/ > > ? > > hmm, yeah, it does.  Oh well, nevermind for awhile. > > > I remember the last time I tried to clean this up, it took a while... > > It seems like something the build tools should > handle correctly now, but I'll look at it. Nah, I think it's fine the way it is. What's wrong with the "../" type things in the include directives? The build system works well with it, you can build any single module or file correctly, and it's obvious what the code is including from. Now you might argue that the lustre code shouldn't have such a mess of include files like this, and I would totally agree. I suggest working on reducing the number of .h files they have, and centralizing them such that all of these cross-directory includes aren't needed anymore either in the build directives, or in the .c files. thanks, greg k-h