| Message ID | 53A1ECD0.2030001@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. :)
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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