Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 02/16 v5] core/pkg-utils: add macro to hardlink-or-copy
Date: Sun, 20 Mar 2016 00:33:42 +0100	[thread overview]
Message-ID: <20160319233342.GI3426@free.fr> (raw)
In-Reply-To: <56ED7967.8050200@mind.be>

Arnout, All,

On 2016-03-19 17:08 +0100, Arnout Vandecappelle spake thusly:
> On 03/19/16 15:23, Thomas Petazzoni wrote:
> >On Fri, 11 Mar 2016 18:49:15 +0100, Yann E. MORIN wrote:
> >
> >>+################################################################################
> >>+# hardlink-copy -- hardlink source and destination if possible, otherwise
> >>+# do a simple copy
> >>+#
> >>+# argument 1 is the source *file*
> >>+# argument 2 is the destination *directory*
> >>+# argument 3 is the basename of the destination file (optional, defaults to
> >>+#            the basename of the source file.
> >>+#
> >>+# examples:
> >>+#   $(call hardlink-copy,/path/to/source/file,/path/to/destination/dir)
> >>+#   $(call hardlink-copy,/path/to/source/file,/path/to/destination/dir,new-name)
> >>+#
> >>+# Notes:
> >>+#  - this is NOT an atomic operation,
> >>+#  - this is only a wrapper to a shell script, so that it can be used with
> >>+#    shell-level variables, like in a for loop.
> >>+################################################################################
> >>+define hardlink-copy
> >>+	support/scripts/hardlink-copy "$(strip $(1))" "$(strip $(2))" "$(strip $(3))"
> >>+endef
> >
> >While in certain cases, I agree that a shell wrapper is nice and
> >useful, here I really don't see the point of a shell wrapper. You can
> >simply do (untested):
> >
> >define hardlink-or-copy-inner
> >	rm -f $(2)
> >	ln -f $(1) $(2) 2>/dev/null || cp -f $(1) $(2)
> >endef
> >
> >define hardlink-or-copy
> >	$(call hardlink-or-copy-inner,$(1),$(if $(3),$(2)/$(3),$(2)/$(basename $(1))))
> >endef
> 
>  I disagree. This may be slightly shorter in lines of code, but I think the
> shell script is much more readable.

And as explained in the commit log, it does not work if any of the
argument needs shell-level expansion (see my other reply to Thomas).

>  However, I do wonder if it makes sense to have a make function for it if
> there already is a shell script. We don't do that for apply-patches, so why
> would we do it for this one?

As explained in the ocmmit log:
    We still keep the make macro, as it is easier to [call], and allows
    to $(strip) its arguments in a convenient fashion.

Note: I now use "call" when the commit log used "write". What is easier
is not to write the macro (well, it is, but that was not the point of
that sentence), but writing code that calls the macro.

Also, I think it is better to have callers call a make macro, even if
backe by a shell script. It is more "in-line" with how we do other
stuff, like the github helper. Our helpers are make macros, it is more
homogeneous.

> >Note that I think the name of the macro should be hardlink-or-copy and
> >not hardlink-copy. The name hardlink-copy seems to indicate that you
> >are copying a hardlink, which is not what is happening.
> >hardlink-or-copy is IMO clearer on the fact that the macro does a hardlink
> >or a copy.
> 
>  I agree with that.

Fixed.

Thanks! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2016-03-19 23:33 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 17:49 [Buildroot] [PATCH 00/16 v5] legal-info improvements and completeness (branch yem/legal-3) Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 01/16 v5] toolchain/external: add hashes for actual sources Yann E. MORIN
2016-03-19 15:31   ` Thomas Petazzoni
2016-03-11 17:49 ` [Buildroot] [PATCH 02/16 v5] core/pkg-utils: add macro to hardlink-or-copy Yann E. MORIN
2016-03-19 14:23   ` Thomas Petazzoni
2016-03-19 16:08     ` Arnout Vandecappelle
2016-03-19 23:33       ` Yann E. MORIN [this message]
2016-03-20 13:21         ` Thomas Petazzoni
2016-03-22 22:32         ` Arnout Vandecappelle
2016-03-19 23:11     ` Yann E. MORIN
2016-03-20 13:29       ` Thomas Petazzoni
2016-03-11 17:49 ` [Buildroot] [PATCH 03/16 v5] core/legal-info: use the macro to install source archives Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 04/16 v5] core/pkg-generic: reorder variables definitions for legal-info Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 05/16 v5] core/legal-info: ensure legal-info works in off-line mode Yann E. MORIN
2016-03-19 14:47   ` Thomas Petazzoni
2016-03-19 18:18     ` Yann E. MORIN
2016-04-28 21:57     ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 06/16 v5] core/pkg-generic: add variable to store the package rawname-version Yann E. MORIN
2016-03-19 14:48   ` Thomas Petazzoni
2016-03-19 18:20     ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 07/16 v5] core/legal-info: install source archives in their own sub-dir Yann E. MORIN
2016-03-19 14:51   ` Thomas Petazzoni
2016-03-11 17:49 ` [Buildroot] [PATCH 08/16 v5] core/legal-info: add package version to license directory Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 09/16 v5] core/apply-patches: store full path of applied patches Yann E. MORIN
2016-03-19 15:03   ` Thomas Petazzoni
2016-03-19 18:51     ` Yann E. MORIN
2016-03-19 22:37       ` Yann E. MORIN
2016-03-20 13:47         ` Thomas Petazzoni
2016-03-20 16:28           ` Arnout Vandecappelle
2016-03-11 17:49 ` [Buildroot] [PATCH 10/16 v5] core/legal-info: also save patches Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 11/16 v5] core/legal-info: renumber saved patches Yann E. MORIN
2016-03-19 15:05   ` Thomas Petazzoni
2016-03-19 23:34     ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 12/16 v5] core/legal-info: also save extra downloads Yann E. MORIN
2016-03-19 15:14   ` Thomas Petazzoni
2016-03-20 16:33     ` Arnout Vandecappelle
2016-03-11 17:49 ` [Buildroot] [PATCH 13/16 v5] core/legal-info: generate a hash of all saved files Yann E. MORIN
2016-03-19 15:21   ` Thomas Petazzoni
2016-03-19 23:40     ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 14/16 v5] core/legal-info: allow ignoring packages from the legal-info Yann E. MORIN
2016-03-19 15:29   ` Thomas Petazzoni
2016-03-19 23:48     ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 15/16 v5] core/pkg-virtual: ignore from legal-info output Yann E. MORIN
2016-03-27 20:47   ` Arnout Vandecappelle
2016-03-11 17:49 ` [Buildroot] [PATCH 16/16 v5] legal-info: explicitly state how patches are licensed Yann E. MORIN
2016-03-27 20:49   ` Arnout Vandecappelle

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=20160319233342.GI3426@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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