relative objtree change broke tar builds?

relative objtree change broke tar builds?

[J. Bruce Fields]

The scripts I use for my kernel testing rely on the targz-pkg make
target.  After updating to 3.16-rc1 my scripts started failing.  In
scripts/package/buildtar:

  tmpdir="${objtree}/tar-install"
  tarball="${objtree}/linux-${KERNELRELEASE}-${ARCH}.tar"
..
  #
  # Create the tarball
  #
  (
        cd "${tmpdir}"
        opts=
        if tar --owner=root --group=root --help >/dev/null 2>&1; then
                opts="--owner=root --group=root"
        fi
        tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
  )


After 7e1c04779efd511 "kbuild: Use relative path for $(objtree)", that's a
relative instead of absolute path so the tarball's dumped by default into
tmpdir, not what was intended.

The changelog there says

	The main Makefile sets its working directory to the object tree
	and never changes it again. Therefore, we can use '.' instead of
	the absolute path.

But the main Makefile also exports objtree, and a quick grep suggests
lots of other uses outside the main Makefile.

--b.

Re: relative objtree change broke tar builds?

[Michal Marek]

Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
> The scripts I use for my kernel testing rely on the targz-pkg make
> target.  After updating to 3.16-rc1 my scripts started failing.  In
> scripts/package/buildtar:
> 
>   tmpdir="${objtree}/tar-install"
>   tarball="${objtree}/linux-${KERNELRELEASE}-${ARCH}.tar"
> ..
>   #
>   # Create the tarball
>   #
>   (
>         cd "${tmpdir}"
>         opts=
>         if tar --owner=root --group=root --help >/dev/null 2>&1; then
>                 opts="--owner=root --group=root"
>         fi
>         tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
>   )

Thanks for the report, I'll fix it.


> The changelog there says
> 
> 	The main Makefile sets its working directory to the object tree
> 	and never changes it again. Therefore, we can use '.' instead of
> 	the absolute path.
> 
> But the main Makefile also exports objtree, and a quick grep suggests
> lots of other uses outside the main Makefile.

Do you have examples? Besides your report, I'm only aware of make
deb-pkg and make *docs. What else?

Thanks,
Michal

Re: relative objtree change broke tar builds?

[J. Bruce Fields]

On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
> > The scripts I use for my kernel testing rely on the targz-pkg make
> > target.  After updating to 3.16-rc1 my scripts started failing.  In
> > scripts/package/buildtar:
> > 
> >   tmpdir="${objtree}/tar-install"
> >   tarball="${objtree}/linux-${KERNELRELEASE}-${ARCH}.tar"
> > ..
> >   #
> >   # Create the tarball
> >   #
> >   (
> >         cd "${tmpdir}"
> >         opts=
> >         if tar --owner=root --group=root --help >/dev/null 2>&1; then
> >                 opts="--owner=root --group=root"
> >         fi
> >         tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
> >   )
> 
> Thanks for the report, I'll fix it.

Thanks!

> > The changelog there says
> > 
> > 	The main Makefile sets its working directory to the object tree
> > 	and never changes it again. Therefore, we can use '.' instead of
> > 	the absolute path.
> > 
> > But the main Makefile also exports objtree, and a quick grep suggests
> > lots of other uses outside the main Makefile.
> 
> Do you have examples? Besides your report, I'm only aware of make
> deb-pkg and make *docs. What else?

I haven't looked.

I only note that grep finds 47 files referencing that variable, and
absent some argument that the remaining ones are correct, I'd be
inclined to revert.  But I don't know if there's other work that now
depends on the change.

In any case, your call.

--b.

Re: relative objtree change broke tar builds?

[Michal Marek]

Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>> The changelog there says
>>>
>>> 	The main Makefile sets its working directory to the object tree
>>> 	and never changes it again. Therefore, we can use '.' instead of
>>> 	the absolute path.
>>>
>>> But the main Makefile also exports objtree, and a quick grep suggests
>>> lots of other uses outside the main Makefile.
>>
>> Do you have examples? Besides your report, I'm only aware of make
>> deb-pkg and make *docs. What else?
> 
> I haven't looked.
> 
> I only note that grep finds 47 files referencing that variable, and
> absent some argument that the remaining ones are correct, I'd be
> inclined to revert.

Do these 47 files change the working directory before referencing the
variable?

Thanks,
Michal

Re: relative objtree change broke tar builds?

[J. Bruce Fields]

On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
> > On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
> >> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
> >>> The changelog there says
> >>>
> >>> 	The main Makefile sets its working directory to the object tree
> >>> 	and never changes it again. Therefore, we can use '.' instead of
> >>> 	the absolute path.
> >>>
> >>> But the main Makefile also exports objtree, and a quick grep suggests
> >>> lots of other uses outside the main Makefile.
> >>
> >> Do you have examples? Besides your report, I'm only aware of make
> >> deb-pkg and make *docs. What else?
> > 
> > I haven't looked.
> > 
> > I only note that grep finds 47 files referencing that variable, and
> > absent some argument that the remaining ones are correct, I'd be
> > inclined to revert.
> 
> Do these 47 files change the working directory before referencing the
> variable?

Sorry, I'm not volunteering to check.

Note also that other variables are defined in terms of objtree, and they
may be exported or passed to other scripts.

--b.

[PATCH] kbuild: Fix tar-pkg with relative $(objtree)

[Michal Marek]

Commit 7e1c0477 (kbuild: Use relative path for $(objtree)) assumes that
the build process does not change its working directory. make tar-pkg
was a couterexample, fix this by changing directory only for the tar
command and not for the whole script, which at one point references the
now relative $(objtree).

Reported-by: "J. Bruce Fields" <bfields@fieldses.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
 scripts/package/buildtar | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 995c1ea..e046bff 100644
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -125,12 +125,11 @@ esac
 # Create the tarball
 #
 (
-	cd "${tmpdir}"
 	opts=
 	if tar --owner=root --group=root --help >/dev/null 2>&1; then
 		opts="--owner=root --group=root"
 	fi
-	tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
+	tar cf - -C "$tmpdir" boot/ lib/ $opts | ${compress} > "${tarball}${file_ext}"
 )
 
 echo "Tarball successfully created in ${tarball}${file_ext}"
-- 
1.9.2

Re: [PATCH] kbuild: Fix tar-pkg with relative $(objtree)

[J. Bruce Fields]

On Wed, Jun 18, 2014 at 04:26:23PM +0200, Michal Marek wrote:
> Commit 7e1c0477 (kbuild: Use relative path for $(objtree)) assumes that
> the build process does not change its working directory. make tar-pkg
> was a couterexample, fix this by changing directory only for the tar
> command and not for the whole script, which at one point references the
> now relative $(objtree).

Works for me, thanks.--b.

> 
> Reported-by: "J. Bruce Fields" <bfields@fieldses.org>
> Signed-off-by: Michal Marek <mmarek@suse.cz>
> ---
>  scripts/package/buildtar | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> index 995c1ea..e046bff 100644
> --- a/scripts/package/buildtar
> +++ b/scripts/package/buildtar
> @@ -125,12 +125,11 @@ esac
>  # Create the tarball
>  #
>  (
> -	cd "${tmpdir}"
>  	opts=
>  	if tar --owner=root --group=root --help >/dev/null 2>&1; then
>  		opts="--owner=root --group=root"
>  	fi
> -	tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
> +	tar cf - -C "$tmpdir" boot/ lib/ $opts | ${compress} > "${tarball}${file_ext}"
>  )
>  
>  echo "Tarball successfully created in ${tarball}${file_ext}"
> -- 
> 1.9.2
> 

Re: [PATCH] kbuild: Fix tar-pkg with relative $(objtree)

[Michal Marek]

Dne 18.6.2014 17:29, J. Bruce Fields napsal(a):
> On Wed, Jun 18, 2014 at 04:26:23PM +0200, Michal Marek wrote:
>> Commit 7e1c0477 (kbuild: Use relative path for $(objtree)) assumes that
>> the build process does not change its working directory. make tar-pkg
>> was a couterexample, fix this by changing directory only for the tar
>> command and not for the whole script, which at one point references the
>> now relative $(objtree).
> 
> Works for me, thanks.--b.

Thanks for testing!

Michal

Re: relative objtree change broke tar builds?

[Randy Dunlap]

On 06/18/14 06:14, J. Bruce Fields wrote:
> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>>>> The changelog there says
>>>>>
>>>>> 	The main Makefile sets its working directory to the object tree
>>>>> 	and never changes it again. Therefore, we can use '.' instead of
>>>>> 	the absolute path.
>>>>>
>>>>> But the main Makefile also exports objtree, and a quick grep suggests
>>>>> lots of other uses outside the main Makefile.
>>>>
>>>> Do you have examples? Besides your report, I'm only aware of make
>>>> deb-pkg and make *docs. What else?
>>>
>>> I haven't looked.
>>>
>>> I only note that grep finds 47 files referencing that variable, and
>>> absent some argument that the remaining ones are correct, I'd be
>>> inclined to revert.
>>
>> Do these 47 files change the working directory before referencing the
>> variable?
> 
> Sorry, I'm not volunteering to check.
> 
> Note also that other variables are defined in terms of objtree, and they
> may be exported or passed to other scripts.


I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is
generating ./Makefile.  I want to see the real path there instead of '.'.


-- 
~Randy

Re: relative objtree change broke tar builds?

[Michal Marek]

Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
> On 06/18/14 06:14, J. Bruce Fields wrote:
>> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
>>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
>>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>>>>> The changelog there says
>>>>>>
>>>>>> 	The main Makefile sets its working directory to the object tree
>>>>>> 	and never changes it again. Therefore, we can use '.' instead of
>>>>>> 	the absolute path.
>>>>>>
>>>>>> But the main Makefile also exports objtree, and a quick grep suggests
>>>>>> lots of other uses outside the main Makefile.
>>>>>
>>>>> Do you have examples? Besides your report, I'm only aware of make
>>>>> deb-pkg and make *docs. What else?
>>>>
>>>> I haven't looked.
>>>>
>>>> I only note that grep finds 47 files referencing that variable, and
>>>> absent some argument that the remaining ones are correct, I'd be
>>>> inclined to revert.
>>>
>>> Do these 47 files change the working directory before referencing the
>>> variable?
>>
>> Sorry, I'm not volunteering to check.
>>
>> Note also that other variables are defined in terms of objtree, and they
>> may be exported or passed to other scripts.
> 
> 
> I'll note one side effect that I really dislike:
> If not in silent mode, scripts/mkmakefile tells me that the it is
> generating ./Makefile.  I want to see the real path there instead of '.'.

The idea is that one should be able to compare as much as possible
between the build of /usr/src/linux-<version_a> built in
/usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
/usr/src/linux-<version_b>/build. One can now even compare the build log
with -j1, although that was not the primary goal. So if the changed
message is considered problematic, I can change it to show the full path
again, like

diff --git a/scripts/mkmakefile b/scripts/mkmakefile
index 84af27b..9d291f5 100644
--- a/scripts/mkmakefile
+++ b/scripts/mkmakefile
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi

 cat << EOF > $2/Makefile

Opinions?

Thanks,
Michal

Re: relative objtree change broke tar builds?

[Sam Ravnborg]

On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
> Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
> > On 06/18/14 06:14, J. Bruce Fields wrote:
> >> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
> >>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
> >>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
> >>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
> >>>>>> The changelog there says
> >>>>>>
> >>>>>> 	The main Makefile sets its working directory to the object tree
> >>>>>> 	and never changes it again. Therefore, we can use '.' instead of
> >>>>>> 	the absolute path.
> >>>>>>
> >>>>>> But the main Makefile also exports objtree, and a quick grep suggests
> >>>>>> lots of other uses outside the main Makefile.
> >>>>>
> >>>>> Do you have examples? Besides your report, I'm only aware of make
> >>>>> deb-pkg and make *docs. What else?
> >>>>
> >>>> I haven't looked.
> >>>>
> >>>> I only note that grep finds 47 files referencing that variable, and
> >>>> absent some argument that the remaining ones are correct, I'd be
> >>>> inclined to revert.
> >>>
> >>> Do these 47 files change the working directory before referencing the
> >>> variable?
> >>
> >> Sorry, I'm not volunteering to check.
> >>
> >> Note also that other variables are defined in terms of objtree, and they
> >> may be exported or passed to other scripts.
> > 
> > 
> > I'll note one side effect that I really dislike:
> > If not in silent mode, scripts/mkmakefile tells me that the it is
> > generating ./Makefile.  I want to see the real path there instead of '.'.
> 
> The idea is that one should be able to compare as much as possible
> between the build of /usr/src/linux-<version_a> built in
> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
> /usr/src/linux-<version_b>/build. One can now even compare the build log
> with -j1, although that was not the primary goal. So if the changed
> message is considered problematic, I can change it to show the full path
> again, like
> 
> diff --git a/scripts/mkmakefile b/scripts/mkmakefile
> index 84af27b..9d291f5 100644
> --- a/scripts/mkmakefile
> +++ b/scripts/mkmakefile
> @@ -18,7 +18,7 @@ then
>         exit 0
>  fi
>  if [ "${quiet}" != "silent_" ]; then
> -       echo "  GEN     $2/Makefile"
> +       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
>  fi
> 
>  cat << EOF > $2/Makefile
> 
> Opinions?
I agree with Randy - the full path is more informative.

	Sam

Re: relative objtree change broke tar builds?

[Randy Dunlap]

On 06/18/14 12:52, Sam Ravnborg wrote:
> On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
>> Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
>>> On 06/18/14 06:14, J. Bruce Fields wrote:
>>>> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
>>>>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
>>>>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>>>>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>>>>>>> The changelog there says
>>>>>>>>
>>>>>>>> 	The main Makefile sets its working directory to the object tree
>>>>>>>> 	and never changes it again. Therefore, we can use '.' instead of
>>>>>>>> 	the absolute path.
>>>>>>>>
>>>>>>>> But the main Makefile also exports objtree, and a quick grep suggests
>>>>>>>> lots of other uses outside the main Makefile.
>>>>>>>
>>>>>>> Do you have examples? Besides your report, I'm only aware of make
>>>>>>> deb-pkg and make *docs. What else?
>>>>>>
>>>>>> I haven't looked.
>>>>>>
>>>>>> I only note that grep finds 47 files referencing that variable, and
>>>>>> absent some argument that the remaining ones are correct, I'd be
>>>>>> inclined to revert.
>>>>>
>>>>> Do these 47 files change the working directory before referencing the
>>>>> variable?
>>>>
>>>> Sorry, I'm not volunteering to check.
>>>>
>>>> Note also that other variables are defined in terms of objtree, and they
>>>> may be exported or passed to other scripts.
>>>
>>>
>>> I'll note one side effect that I really dislike:
>>> If not in silent mode, scripts/mkmakefile tells me that the it is
>>> generating ./Makefile.  I want to see the real path there instead of '.'.
>>
>> The idea is that one should be able to compare as much as possible
>> between the build of /usr/src/linux-<version_a> built in
>> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
>> /usr/src/linux-<version_b>/build. One can now even compare the build log
>> with -j1, although that was not the primary goal. So if the changed
>> message is considered problematic, I can change it to show the full path
>> again, like
>>
>> diff --git a/scripts/mkmakefile b/scripts/mkmakefile
>> index 84af27b..9d291f5 100644
>> --- a/scripts/mkmakefile
>> +++ b/scripts/mkmakefile
>> @@ -18,7 +18,7 @@ then
>>         exit 0
>>  fi
>>  if [ "${quiet}" != "silent_" ]; then
>> -       echo "  GEN     $2/Makefile"
>> +       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
>>  fi
>>
>>  cat << EOF > $2/Makefile
>>
>> Opinions?
> I agree with Randy - the full path is more informative.
> 
> 	Sam

Yes, just '.' discards some very useful information.

-- 
~Randy

Re: relative objtree change broke tar builds?

[Randy Dunlap]

On 06/18/14 12:47, Michal Marek wrote:
> Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
>> On 06/18/14 06:14, J. Bruce Fields wrote:
>>> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
>>>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
>>>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>>>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>>>>>> The changelog there says
>>>>>>>
>>>>>>> 	The main Makefile sets its working directory to the object tree
>>>>>>> 	and never changes it again. Therefore, we can use '.' instead of
>>>>>>> 	the absolute path.
>>>>>>>
>>>>>>> But the main Makefile also exports objtree, and a quick grep suggests
>>>>>>> lots of other uses outside the main Makefile.
>>>>>>
>>>>>> Do you have examples? Besides your report, I'm only aware of make
>>>>>> deb-pkg and make *docs. What else?
>>>>>
>>>>> I haven't looked.
>>>>>
>>>>> I only note that grep finds 47 files referencing that variable, and
>>>>> absent some argument that the remaining ones are correct, I'd be
>>>>> inclined to revert.
>>>>
>>>> Do these 47 files change the working directory before referencing the
>>>> variable?
>>>
>>> Sorry, I'm not volunteering to check.
>>>
>>> Note also that other variables are defined in terms of objtree, and they
>>> may be exported or passed to other scripts.
>>
>>
>> I'll note one side effect that I really dislike:
>> If not in silent mode, scripts/mkmakefile tells me that the it is
>> generating ./Makefile.  I want to see the real path there instead of '.'.
> 
> The idea is that one should be able to compare as much as possible
> between the build of /usr/src/linux-<version_a> built in
> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
> /usr/src/linux-<version_b>/build. One can now even compare the build log
> with -j1, although that was not the primary goal. So if the changed
> message is considered problematic, I can change it to show the full path
> again, like
> 
> diff --git a/scripts/mkmakefile b/scripts/mkmakefile
> index 84af27b..9d291f5 100644
> --- a/scripts/mkmakefile
> +++ b/scripts/mkmakefile
> @@ -18,7 +18,7 @@ then
>         exit 0
>  fi
>  if [ "${quiet}" != "silent_" ]; then
> -       echo "  GEN     $2/Makefile"
> +       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
>  fi
> 
>  cat << EOF > $2/Makefile
> 
> Opinions?

works for me.  Thanks.


-- 
~Randy

Re: relative objtree change broke tar builds?

[Ken Moffat]

On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
> 
> The idea is that one should be able to compare as much as possible
> between the build of /usr/src/linux-<version_a> built in
> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
> /usr/src/linux-<version_b>/build.

Michal,

 Now that you have sent a pull request to Linus, and therefore
addressed the main problem, may I dare to question your example ?

 I only started building kernels in (approximately) spring 2000, so I
am sure that I am missing a lot of history.  But /usr/src/linux*
smells of "tradition" in the Scots sense of "whit ma faither telt me
that his faither telt him" ("what my father told me that his father
told him" in english).  I am sure that /usr/src/linux might have been
an expectation in the distant past, but it tends to bring along the
assumption that kernels are _built_ by that dangerous guy called
'root'.

 Some of us (me included) often build things as root, but it has
many risks and people ought not to be led to believe it is
necessarily the correct way to do things.  Over the past 14 years I
have built kernels in ~/ as well as in other user-writable
directories and I am puzzled about why the idea of /usr/src/linux*
continues to exist.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.

Re: relative objtree change broke tar builds?

[Michal Marek]

Dne 18.6.2014 23:13, Randy Dunlap napsal(a):
> On 06/18/14 12:52, Sam Ravnborg wrote:
>> On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
>>> Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
>>>> On 06/18/14 06:14, J. Bruce Fields wrote:
>>>>> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
>>>>>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
>>>>>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>>>>>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>>>>>>>> The changelog there says
>>>>>>>>>
>>>>>>>>> 	The main Makefile sets its working directory to the object tree
>>>>>>>>> 	and never changes it again. Therefore, we can use '.' instead of
>>>>>>>>> 	the absolute path.
>>>>>>>>>
>>>>>>>>> But the main Makefile also exports objtree, and a quick grep suggests
>>>>>>>>> lots of other uses outside the main Makefile.
>>>>>>>>
>>>>>>>> Do you have examples? Besides your report, I'm only aware of make
>>>>>>>> deb-pkg and make *docs. What else?
>>>>>>>
>>>>>>> I haven't looked.
>>>>>>>
>>>>>>> I only note that grep finds 47 files referencing that variable, and
>>>>>>> absent some argument that the remaining ones are correct, I'd be
>>>>>>> inclined to revert.
>>>>>>
>>>>>> Do these 47 files change the working directory before referencing the
>>>>>> variable?
>>>>>
>>>>> Sorry, I'm not volunteering to check.
>>>>>
>>>>> Note also that other variables are defined in terms of objtree, and they
>>>>> may be exported or passed to other scripts.
>>>>
>>>>
>>>> I'll note one side effect that I really dislike:
>>>> If not in silent mode, scripts/mkmakefile tells me that the it is
>>>> generating ./Makefile.  I want to see the real path there instead of '.'.
>>>
>>> The idea is that one should be able to compare as much as possible
>>> between the build of /usr/src/linux-<version_a> built in
>>> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
>>> /usr/src/linux-<version_b>/build. One can now even compare the build log
>>> with -j1, although that was not the primary goal. So if the changed
>>> message is considered problematic, I can change it to show the full path
>>> again, like
>>>
>>> diff --git a/scripts/mkmakefile b/scripts/mkmakefile
>>> index 84af27b..9d291f5 100644
>>> --- a/scripts/mkmakefile
>>> +++ b/scripts/mkmakefile
>>> @@ -18,7 +18,7 @@ then
>>>         exit 0
>>>  fi
>>>  if [ "${quiet}" != "silent_" ]; then
>>> -       echo "  GEN     $2/Makefile"
>>> +       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
>>>  fi
>>>
>>>  cat << EOF > $2/Makefile
>>>
>>> Opinions?
>> I agree with Randy - the full path is more informative.
>>
>> 	Sam
> 
> Yes, just '.' discards some very useful information.

With commit c2e28dc9 ("kbuild: Print the name of the build directory"),
it now prints the full path at the beginning of each make invocation. So
I think it is not necessary to repeat the full path a few lines later,
do you agree?

Thanks,
Michal

Re: relative objtree change broke tar builds?

[Randy Dunlap]

On 07/04/2014 02:37 PM, Michal Marek wrote:
> Dne 18.6.2014 23:13, Randy Dunlap napsal(a):
>> On 06/18/14 12:52, Sam Ravnborg wrote:
>>> On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
>>>> Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
>>>>> On 06/18/14 06:14, J. Bruce Fields wrote:
>>>>>> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
>>>>>>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
>>>>>>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>>>>>>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>>>>>>>>> The changelog there says
>>>>>>>>>>
>>>>>>>>>> 	The main Makefile sets its working directory to the object tree
>>>>>>>>>> 	and never changes it again. Therefore, we can use '.' instead of
>>>>>>>>>> 	the absolute path.
>>>>>>>>>>
>>>>>>>>>> But the main Makefile also exports objtree, and a quick grep suggests
>>>>>>>>>> lots of other uses outside the main Makefile.
>>>>>>>>>
>>>>>>>>> Do you have examples? Besides your report, I'm only aware of make
>>>>>>>>> deb-pkg and make *docs. What else?
>>>>>>>>
>>>>>>>> I haven't looked.
>>>>>>>>
>>>>>>>> I only note that grep finds 47 files referencing that variable, and
>>>>>>>> absent some argument that the remaining ones are correct, I'd be
>>>>>>>> inclined to revert.
>>>>>>>
>>>>>>> Do these 47 files change the working directory before referencing the
>>>>>>> variable?
>>>>>>
>>>>>> Sorry, I'm not volunteering to check.
>>>>>>
>>>>>> Note also that other variables are defined in terms of objtree, and they
>>>>>> may be exported or passed to other scripts.
>>>>>
>>>>>
>>>>> I'll note one side effect that I really dislike:
>>>>> If not in silent mode, scripts/mkmakefile tells me that the it is
>>>>> generating ./Makefile.  I want to see the real path there instead of '.'.
>>>>
>>>> The idea is that one should be able to compare as much as possible
>>>> between the build of /usr/src/linux-<version_a> built in
>>>> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
>>>> /usr/src/linux-<version_b>/build. One can now even compare the build log
>>>> with -j1, although that was not the primary goal. So if the changed
>>>> message is considered problematic, I can change it to show the full path
>>>> again, like
>>>>
>>>> diff --git a/scripts/mkmakefile b/scripts/mkmakefile
>>>> index 84af27b..9d291f5 100644
>>>> --- a/scripts/mkmakefile
>>>> +++ b/scripts/mkmakefile
>>>> @@ -18,7 +18,7 @@ then
>>>>         exit 0
>>>>  fi
>>>>  if [ "${quiet}" != "silent_" ]; then
>>>> -       echo "  GEN     $2/Makefile"
>>>> +       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
>>>>  fi
>>>>
>>>>  cat << EOF > $2/Makefile
>>>>
>>>> Opinions?
>>> I agree with Randy - the full path is more informative.
>>>
>>> 	Sam
>>
>> Yes, just '.' discards some very useful information.
> 
> With commit c2e28dc9 ("kbuild: Print the name of the build directory"),
> it now prints the full path at the beginning of each make invocation. So
> I think it is not necessary to repeat the full path a few lines later,
> do you agree?

Sounds possible, but I'll test it early next week.
BTW, you are offline.  :)



-- 
~Randy

Re: relative objtree change broke tar builds?

[Michal Marek]

Dne 19.6.2014 03:21, Ken Moffat napsal(a):
> On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
>>
>> The idea is that one should be able to compare as much as possible
>> between the build of /usr/src/linux-<version_a> built in
>> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
>> /usr/src/linux-<version_b>/build.
> [...]
>  Some of us (me included) often build things as root, but it has
> many risks and people ought not to be led to believe it is
> necessarily the correct way to do things.  Over the past 14 years I
> have built kernels in ~/ as well as in other user-writable
> directories and I am puzzled about why the idea of /usr/src/linux*
> continues to exist.

I just used /usr/src/linux as an example. If I wrote
/dev/shm/linux-2.6/build, which is where I often builf kernels, then I'm
sure somebody would complain that they tried it and ran out of memory :-).

Michal

Re: relative objtree change broke tar builds?

[Randy Dunlap]

On 07/04/2014 02:37 PM, Michal Marek wrote:
> Dne 18.6.2014 23:13, Randy Dunlap napsal(a):
>> On 06/18/14 12:52, Sam Ravnborg wrote:
>>> On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
>>>> Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
>>>>> On 06/18/14 06:14, J. Bruce Fields wrote:
>>>>>> On Wed, Jun 18, 2014 at 02:33:22PM +0200, Michal Marek wrote:
>>>>>>> Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
>>>>>>>> On Wed, Jun 18, 2014 at 11:06:12AM +0200, Michal Marek wrote:
>>>>>>>>> Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
>>>>>>>>>> The changelog there says
>>>>>>>>>>
>>>>>>>>>> 	The main Makefile sets its working directory to the object tree
>>>>>>>>>> 	and never changes it again. Therefore, we can use '.' instead of
>>>>>>>>>> 	the absolute path.
>>>>>>>>>>
>>>>>>>>>> But the main Makefile also exports objtree, and a quick grep suggests
>>>>>>>>>> lots of other uses outside the main Makefile.
>>>>>>>>>
>>>>>>>>> Do you have examples? Besides your report, I'm only aware of make
>>>>>>>>> deb-pkg and make *docs. What else?
>>>>>>>>
>>>>>>>> I haven't looked.
>>>>>>>>
>>>>>>>> I only note that grep finds 47 files referencing that variable, and
>>>>>>>> absent some argument that the remaining ones are correct, I'd be
>>>>>>>> inclined to revert.
>>>>>>>
>>>>>>> Do these 47 files change the working directory before referencing the
>>>>>>> variable?
>>>>>>
>>>>>> Sorry, I'm not volunteering to check.
>>>>>>
>>>>>> Note also that other variables are defined in terms of objtree, and they
>>>>>> may be exported or passed to other scripts.
>>>>>
>>>>>
>>>>> I'll note one side effect that I really dislike:
>>>>> If not in silent mode, scripts/mkmakefile tells me that the it is
>>>>> generating ./Makefile.  I want to see the real path there instead of '.'.
>>>>
>>>> The idea is that one should be able to compare as much as possible
>>>> between the build of /usr/src/linux-<version_a> built in
>>>> /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in
>>>> /usr/src/linux-<version_b>/build. One can now even compare the build log
>>>> with -j1, although that was not the primary goal. So if the changed
>>>> message is considered problematic, I can change it to show the full path
>>>> again, like
>>>>
>>>> diff --git a/scripts/mkmakefile b/scripts/mkmakefile
>>>> index 84af27b..9d291f5 100644
>>>> --- a/scripts/mkmakefile
>>>> +++ b/scripts/mkmakefile
>>>> @@ -18,7 +18,7 @@ then
>>>>         exit 0
>>>>  fi
>>>>  if [ "${quiet}" != "silent_" ]; then
>>>> -       echo "  GEN     $2/Makefile"
>>>> +       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
>>>>  fi
>>>>
>>>>  cat << EOF > $2/Makefile
>>>>
>>>> Opinions?
>>> I agree with Randy - the full path is more informative.
>>>
>>> 	Sam
>>
>> Yes, just '.' discards some very useful information.
> 
> With commit c2e28dc9 ("kbuild: Print the name of the build directory"),
> it now prints the full path at the beginning of each make invocation. So
> I think it is not necessary to repeat the full path a few lines later,
> do you agree?

Yes, I am OK with this directory output now.

Thanks.


-- 
~Randy