All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Schier <nicolas@fjasle.eu>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Tom Rix <trix@redhat.com>, Masahiro Yamada <masahiroy@kernel.org>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	bpf@vger.kernel.org, llvm@lists.linux.dev,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 3/5] tools lib subcmd: Add dependency test to install_headers
Date: Tue, 20 Dec 2022 08:33:50 +0100	[thread overview]
Message-ID: <Y6FlXj2IT/5ruI/j@bergen.fjasle.eu> (raw)
In-Reply-To: <CAP-5=fXX5RsCFvGy2_CBYJczauWVemSRB=Bz3nDQ9iufuAXyHg@mail.gmail.com> <20221202045743.2639466-4-irogers@google.com>

[-- Attachment #1: Type: text/plain, Size: 5614 bytes --]

On Mon 19 Dec 2022 14:48:59 GMT, Ian Rogers wrote:
> On Mon, Dec 19, 2022 at 6:44 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
> 
> > On Tue 13 Dec 2022 13:28:21 GMT, Ian Rogers wrote:
> > > On Mon, Dec 12, 2022 at 12:57 PM Nicolas Schier <nicolas@fjasle.eu>
> > wrote:
> > > >
> > > > On Thu, Dec 01, 2022 at 08:57:41PM -0800 Ian Rogers wrote:
> > > > > Compute the headers to be installed from their source headers and
> > make
> > > > > each have its own build target to install it. Using dependencies
> > > > > avoids headers being reinstalled and getting a new timestamp which
> > > > > then causes files that depend on the header to be rebuilt.
> > > > >
> > > > > Signed-off-by: Ian Rogers <irogers@google.com>
> > > > > ---
> > > > >  tools/lib/subcmd/Makefile | 23 +++++++++++++----------
> > > > >  1 file changed, 13 insertions(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/tools/lib/subcmd/Makefile b/tools/lib/subcmd/Makefile
> > > > > index 9a316d8b89df..b87213263a5e 100644
> > > > > --- a/tools/lib/subcmd/Makefile
> > > > > +++ b/tools/lib/subcmd/Makefile
> > > > > @@ -89,10 +89,10 @@ define do_install_mkdir
> > > > >  endef
> > > > >
> > > > >  define do_install
> > > > > -     if [ ! -d '$(DESTDIR_SQ)$2' ]; then             \
> > > > > -             $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$2'; \
> > > > > +     if [ ! -d '$2' ]; then             \
> > > > > +             $(INSTALL) -d -m 755 '$2'; \
> > > > >       fi;                                             \
> > > > > -     $(INSTALL) $1 $(if $3,-m $3,) '$(DESTDIR_SQ)$2'
> > > > > +     $(INSTALL) $1 $(if $3,-m $3,) '$2'
> > > >
> > > > What about using '$(INSTALL) -D ...' instead of the if-mkdir-block
> > above?
> > > > (E.g. as in tools/debugging/Makefile.)
> > > >
> > > > Kind regards,
> > > > Nicolas
> > >
> > > Thanks Nicolas, the reason was to keep the code consistent. That's not
> > > to say this is the best approach. For example, here is the same thing
> > > for tools/lib/api:
> > >
> > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/lib/api/Makefile?h=perf/core&id=f43368371888694a2eceaaad8f5e9775c092009a#n84
> > >
> > > If you'd like to improve this in all the versions and send patches I'd
> > > be happy to take a look.
> > >
> > > Thanks,
> > > Ian
> >
> > Ian, while watching at tools/lib/*/Makefile I stumple across the
> > special single-quote handling (e.g. 'DESTDIR_SQ') several times.
> >
> > Top-level Makefile and kbuild are not designed to work with file or
> > directory names containing spaces.  Do you know whether this is needed
> > for the installation rules in tools/lib/?  I'd like to remove support
> > for path names with spaces for a increasing simplicity and consistency.
> >
> > Kind regards,
> > Nicolas
> >
> 
> Hi Nicolas,
> 
> Simplicity in the files SGTM, my own shell script norms are to be
> cautious/defensive around the interpretation of spaces. The SQ code was
> cargo culted and so may or may not be necessary. The installation rules are
> dealing with user paths which may contain spaces, so I'd encourage some
> caution. We should be able to come up with some command lines that test all
> cases to determine if anything suffers from the changes and whether to care.
> 
> Thanks,
> Ian

Hi Ian,

looking at some of the tools/lib/*/Makefiles and your patch above, the 
use of DESTDIR vs. DESTDIR_SQ seems to be quite inconsistent already:

>  define do_install
> -	if [ ! -d '$(DESTDIR_SQ)$2' ]; then             \
> -		$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$2'; \
> +	if [ ! -d '$2' ]; then             \
> +		$(INSTALL) -d -m 755 '$2'; \
>  	fi;                                             \
> -	$(INSTALL) $1 $(if $3,-m $3,) '$(DESTDIR_SQ)$2'
> +	$(INSTALL) $1 $(if $3,-m $3,) '$2'

Here, the single-quoted DESTDIR_SQ is removed from do_install (which I 
think is a good thing)...

>  endef
>  
>  install_lib: $(LIBFILE)
> @@ -100,13 +100,16 @@ install_lib: $(LIBFILE)
>  		$(call do_install_mkdir,$(libdir_SQ)); \
>  		cp -fpR $(LIBFILE) $(DESTDIR)$(libdir_SQ)
>  
> -install_headers:
> -	$(call QUIET_INSTALL, libsubcmd_headers) \
> -		$(call do_install,exec-cmd.h,$(prefix)/include/subcmd,644); \
> -		$(call do_install,help.h,$(prefix)/include/subcmd,644); \
> -		$(call do_install,pager.h,$(prefix)/include/subcmd,644); \
> -		$(call do_install,parse-options.h,$(prefix)/include/subcmd,644); \
> -		$(call do_install,run-command.h,$(prefix)/include/subcmd,644);
> +HDRS := exec-cmd.h help.h pager.h parse-options.h run-command.h
> +INSTALL_HDRS_PFX := $(DESTDIR)$(prefix)/include/subcmd
> +INSTALL_HDRS := $(addprefix $(INSTALL_HDRS_PFX)/, $(HDRS))
> +
> +$(INSTALL_HDRS): $(INSTALL_HDRS_PFX)/%.h: %.h
> +	$(call QUIET_INSTALL, $@) \
> +		$(call do_install,$<,$(INSTALL_HDRS_PFX)/,644)

... and a plain $(DESTDIR) (via $(INSTALL_HDRS_PFX)) is forwarded to 
do_install.  Doesn't that mean, that we end up with

  $(INSTALL) $< -m 644 '$(DESTDIR)$(prefix)/include/subcmd'

where neither $(DESTDIR) nor $(prefix) has the special single-quote 
handling?  If we would remove the single-quoting and _SQ redefinitions, 
it _should_ be possible (again) to have destination paths with spaces 
(and single quotes), iff users escape properly e.g.
DESTDIR="'/name with space'".  Perhaps a hint about that in the 
Documentation might then be helpful.

Or do I get something completely wrong?

If nobody complains, I am going to prepare a patch for removing the 
single-quote special handling.

Kind regards,
Nicolas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-12-20  7:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02  4:57 [PATCH 0/5] Improvements to incremental builds Ian Rogers
2022-12-02  4:57 ` [PATCH 1/5] tools lib api: Add dependency test to install_headers Ian Rogers
2022-12-02  4:57 ` [PATCH 2/5] tools lib perf: " Ian Rogers
2022-12-16  9:44   ` Alexander Gordeev
2022-12-16  9:50     ` [PATCH] tools lib perf: fix install_pkgconfig target Alexander Gordeev
2022-12-16 13:02       ` Arnaldo Carvalho de Melo
2022-12-02  4:57 ` [PATCH 3/5] tools lib subcmd: Add dependency test to install_headers Ian Rogers
2022-12-12 20:57   ` Nicolas Schier
2022-12-13 21:28     ` Ian Rogers
2022-12-19 14:44       ` Nicolas Schier
2022-12-20  7:33   ` Nicolas Schier [this message]
2022-12-02  4:57 ` [PATCH 4/5] tools lib symbol: " Ian Rogers
2022-12-02  4:57 ` [PATCH 5/5] perf build: Fix python/perf.so library's name Ian Rogers
2022-12-05 12:50 ` [PATCH 0/5] Improvements to incremental builds Arnaldo Carvalho de Melo
2022-12-12 20:31 ` Nicolas Schier
2022-12-13 21:31   ` Ian Rogers

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=Y6FlXj2IT/5ruI/j@bergen.fjasle.eu \
    --to=nicolas@fjasle.eu \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=trix@redhat.com \
    /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.