From: Thierry Reding <[email protected]>
Avoid forking off a shell to resolve the absolute path of the output
directory when make's builtin $(abspath ...) function will do an
adequate job.
Signed-off-by: Thierry Reding <[email protected]>
---
Makefile | 4 ++--
tools/scripts/Makefile.include | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 173437debc87..c1e3ece3684f 100644
--- a/Makefile
+++ b/Makefile
@@ -1542,11 +1542,11 @@ image_name:
# Clear a bunch of variables before executing the submake
tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
- $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
+ $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/
tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
- $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
+ $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ $*
# Single targets
# ---------------------------------------------------------------------------
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 5467da41dc72..4d34d0729ac9 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -1,7 +1,7 @@
ifneq ($(O),)
ifeq ($(origin O), command line)
dummy := $(if $(shell test -d $(O) || echo $(O)),$(error O=$(O) does not exist),)
- ABSOLUTE_O := $(shell cd $(O) ; pwd)
+ ABSOLUTE_O := $(abspath $(O))
OUTPUT := $(ABSOLUTE_O)/$(if $(subdir),$(subdir)/)
COMMAND_O := O=$(ABSOLUTE_O)
ifeq ($(objtree),)
--
2.8.0
On 2016-04-08 11:15, Thierry Reding wrote:
> From: Thierry Reding <[email protected]>
>
> Avoid forking off a shell to resolve the absolute path of the output
> directory when make's builtin $(abspath ...) function will do an
> adequate job.
The abspath function is not available in make 3.80.
Michal
On Mon, Apr 18, 2016 at 04:46:53PM +0200, Michal Marek wrote:
> On 2016-04-08 11:15, Thierry Reding wrote:
> > From: Thierry Reding <[email protected]>
> >
> > Avoid forking off a shell to resolve the absolute path of the output
> > directory when make's builtin $(abspath ...) function will do an
> > adequate job.
>
> The abspath function is not available in make 3.80.
Do we really support make 3.80? It was released in 2002 and 3.81
followed in April 2006. That makes it a decade old now. I'd be surprised
if anyone was still using it to build recent kernels.
Is there a formal process for increasing the dependencies listed in
Documentation/Changes? Should I simply make that change as part of this
patch? Do we need broad approval?
Thierry
On Mon, 18 Apr 2016, Thierry Reding wrote:
> > > Avoid forking off a shell to resolve the absolute path of the output
> > > directory when make's builtin $(abspath ...) function will do an
> > > adequate job.
> >
> > The abspath function is not available in make 3.80.
>
> Do we really support make 3.80? It was released in 2002 and 3.81
> followed in April 2006. That makes it a decade old now. I'd be surprised
> if anyone was still using it to build recent kernels.
>
> Is there a formal process for increasing the dependencies listed in
> Documentation/Changes? Should I simply make that change as part of this
> patch? Do we need broad approval?
Hmm, what problem are you trying to solve here? Your proposal looks to
me like a gratuitous requirement for users to upgrade their tool (its age
doesn't matter), which is often a burden and in any case requires extra
time which could be used for something else. Don't fix what ain't broke!
Maciej
On Mon, Apr 18, 2016 at 04:17:26PM +0100, Maciej W. Rozycki wrote:
> On Mon, 18 Apr 2016, Thierry Reding wrote:
>
> > > > Avoid forking off a shell to resolve the absolute path of the output
> > > > directory when make's builtin $(abspath ...) function will do an
> > > > adequate job.
> > >
> > > The abspath function is not available in make 3.80.
> >
> > Do we really support make 3.80? It was released in 2002 and 3.81
> > followed in April 2006. That makes it a decade old now. I'd be surprised
> > if anyone was still using it to build recent kernels.
> >
> > Is there a formal process for increasing the dependencies listed in
> > Documentation/Changes? Should I simply make that change as part of this
> > patch? Do we need broad approval?
>
> Hmm, what problem are you trying to solve here? Your proposal looks to
> me like a gratuitous requirement for users to upgrade their tool (its age
> doesn't matter), which is often a burden and in any case requires extra
> time which could be used for something else. Don't fix what ain't broke!
Fine.
Thierry