All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Michal Marek <mmarek@suse.cz>, Sam Ravnborg <sam@ravnborg.org>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: relative objtree change broke tar builds?
Date: Sun, 06 Jul 2014 18:04:12 -0700	[thread overview]
Message-ID: <53B9F20C.2020901@infradead.org> (raw)
In-Reply-To: <53B71E83.3010005@suse.cz>

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

  parent reply	other threads:[~2014-07-07  1:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17 22:38 relative objtree change broke tar builds? J. Bruce Fields
2014-06-18  9:06 ` Michal Marek
2014-06-18 12:20   ` J. Bruce Fields
2014-06-18 12:33     ` Michal Marek
2014-06-18 13:14       ` J. Bruce Fields
2014-06-18 15:58         ` Randy Dunlap
2014-06-18 19:47           ` Michal Marek
2014-06-18 19:52             ` Sam Ravnborg
2014-06-18 21:13               ` Randy Dunlap
2014-07-04 21:37                 ` Michal Marek
2014-07-04 21:40                   ` Randy Dunlap
2014-07-07  1:04                   ` Randy Dunlap [this message]
2014-06-18 21:20             ` Randy Dunlap
2014-06-19  1:21             ` Ken Moffat
2014-07-04 21:42               ` Michal Marek
2014-06-18 14:26 ` [PATCH] kbuild: Fix tar-pkg with relative $(objtree) Michal Marek
2014-06-18 15:29   ` J. Bruce Fields
2014-06-18 15:34     ` Michal Marek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B9F20C.2020901@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=bfields@fieldses.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.