[PATCH] btrfs-progs: set include path relatively

[PATCH] btrfs-progs: set include path relatively

[Naohiro Aota]

Currently, gcc is passed the include directory with full path. As a result,
dependency files (*.o.d) also record the full path at the build time. Such
full path dependency is annoying for sharing the source between multiple
machines, containers, or anything the path differ.

And this is the same way what other program using autotools e.g. e2fsprogs
is doing:

$ grep top_builddir Makefile
top_builddir = .
CPPFLAGS = -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib
BUILD_CFLAGS = -g -O2  -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib -DHAVE_CONFIG_H
<snip>

Signed-off-by: Naohiro Aota <naota@elisp.net>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index b1f3388..69b94fb 100644
--- a/Makefile
+++ b/Makefile
@@ -70,8 +70,8 @@ CFLAGS = $(SUBST_CFLAGS) \
 	 -D_XOPEN_SOURCE=700  \
 	 -fno-strict-aliasing \
 	 -fPIC \
-	 -I$(TOPDIR) \
-	 -I$(TOPDIR)/kernel-lib \
+	 -I. \
+	 -I./kernel-lib \
 	 $(EXTRAWARN_CFLAGS) \
 	 $(DEBUG_CFLAGS_INTERNAL) \
 	 $(EXTRA_CFLAGS)
-- 
2.14.1

Re: [PATCH] btrfs: set include path relatively

[David Sterba]

On Thu, Oct 12, 2017 at 11:22:24AM +0900, Naohiro Aota wrote:
> Currently, gcc is passed the include directory with full path. As a result,
> dependency files (*.o.d) also record the full path at the build time. Such
> full path dependency is annoying for sharing the source between multiple
> machines, containers, or anything the path differ.
> 
> And this is the same way what other program using autotools e.g. e2fsprogs
> is doing:
> 
> $ grep top_builddir Makefile
> top_builddir = .
> CPPFLAGS = -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib
> BUILD_CFLAGS = -g -O2  -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib -DHAVE_CONFIG_H
> <snip>

Makes sense for the header files. TOPDIR is also used for linking, can
it cause similar problems, where the library search path is set as -L$(TOPDIR) ?

I wonder if we should do the same as in the example above and set
default value of TOPDIR to '.', instead of `pwd`.


> Signed-off-by: Naohiro Aota <naota@elisp.net>
> ---
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index b1f3388..69b94fb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -70,8 +70,8 @@ CFLAGS = $(SUBST_CFLAGS) \
>  	 -D_XOPEN_SOURCE=700  \
>  	 -fno-strict-aliasing \
>  	 -fPIC \
> -	 -I$(TOPDIR) \
> -	 -I$(TOPDIR)/kernel-lib \
> +	 -I. \
> +	 -I./kernel-lib \
>  	 $(EXTRAWARN_CFLAGS) \
>  	 $(DEBUG_CFLAGS_INTERNAL) \
>  	 $(EXTRA_CFLAGS)
> -- 
> 2.14.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] btrfs: set include path relatively

[Naohiro Aota]

2017-10-12 21:38 GMT+09:00 David Sterba <dsterba@suse.cz>:
> On Thu, Oct 12, 2017 at 11:22:24AM +0900, Naohiro Aota wrote:
>> Currently, gcc is passed the include directory with full path. As a result,
>> dependency files (*.o.d) also record the full path at the build time. Such
>> full path dependency is annoying for sharing the source between multiple
>> machines, containers, or anything the path differ.
>>
>> And this is the same way what other program using autotools e.g. e2fsprogs
>> is doing:
>>
>> $ grep top_builddir Makefile
>> top_builddir = .
>> CPPFLAGS = -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib
>> BUILD_CFLAGS = -g -O2  -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib -DHAVE_CONFIG_H
>> <snip>
>
> Makes sense for the header files. TOPDIR is also used for linking, can
> it cause similar problems, where the library search path is set as -L$(TOPDIR) ?

Since both "TOPDIR := $(shell pwd)" and -L$(TOPDIR) is evaluated at
the build time,
it never cause problem on linking itself. What the problem with
dependency files is persisting
the full path into the dep files. We generate the dep files only for
objects (%.o.d rule)

Well, it's ok to use "-L." here, and it's the same way with autotools does.

>
> I wonder if we should do the same as in the example above and set
> default value of TOPDIR to '.', instead of `pwd`.

TOPDIR is also used by library-test{,.static}. They run gcc in a
temporary directory.
Thus, TOPDIR here should be absolute.

>
>
>> Signed-off-by: Naohiro Aota <naota@elisp.net>
>> ---
>>  Makefile | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index b1f3388..69b94fb 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -70,8 +70,8 @@ CFLAGS = $(SUBST_CFLAGS) \
>>        -D_XOPEN_SOURCE=700  \
>>        -fno-strict-aliasing \
>>        -fPIC \
>> -      -I$(TOPDIR) \
>> -      -I$(TOPDIR)/kernel-lib \
>> +      -I. \
>> +      -I./kernel-lib \
>>        $(EXTRAWARN_CFLAGS) \
>>        $(DEBUG_CFLAGS_INTERNAL) \
>>        $(EXTRA_CFLAGS)
>> --
>> 2.14.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] btrfs: set include path relatively

[David Sterba]

On Fri, Oct 13, 2017 at 04:01:31PM +0900, Naohiro Aota wrote:
> 2017-10-12 21:38 GMT+09:00 David Sterba <dsterba@suse.cz>:
> > On Thu, Oct 12, 2017 at 11:22:24AM +0900, Naohiro Aota wrote:
> >> Currently, gcc is passed the include directory with full path. As a result,
> >> dependency files (*.o.d) also record the full path at the build time. Such
> >> full path dependency is annoying for sharing the source between multiple
> >> machines, containers, or anything the path differ.
> >>
> >> And this is the same way what other program using autotools e.g. e2fsprogs
> >> is doing:
> >>
> >> $ grep top_builddir Makefile
> >> top_builddir = .
> >> CPPFLAGS = -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib
> >> BUILD_CFLAGS = -g -O2  -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib -DHAVE_CONFIG_H
> >> <snip>
> >
> > Makes sense for the header files. TOPDIR is also used for linking, can
> > it cause similar problems, where the library search path is set as -L$(TOPDIR) ?
> 
> Since both "TOPDIR := $(shell pwd)" and -L$(TOPDIR) is evaluated at
> the build time,
> it never cause problem on linking itself. What the problem with
> dependency files is persisting
> the full path into the dep files. We generate the dep files only for
> objects (%.o.d rule)
> 
> Well, it's ok to use "-L." here, and it's the same way with autotools does.
> 
> > I wonder if we should do the same as in the example above and set
> > default value of TOPDIR to '.', instead of `pwd`.
> 
> TOPDIR is also used by library-test{,.static}. They run gcc in a
> temporary directory.
> Thus, TOPDIR here should be absolute.

I've added another variable with absolute path to make library-test work
and updated your patch so we can use TOPDIR = .