linux-perf-users.vger.kernel.org archive mirror
 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:41 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).