From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 02/16 v5] core/pkg-utils: add macro to hardlink-or-copy
Date: Sat, 19 Mar 2016 17:08:07 +0100 [thread overview]
Message-ID: <56ED7967.8050200@mind.be> (raw)
In-Reply-To: <20160319152307.765e1bad@free-electrons.com>
On 03/19/16 15:23, Thomas Petazzoni wrote:
> Dear Yann E. MORIN,
>
> 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.
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?
>
> 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.
Regards,
Arnout
>
> Thanks!
>
> Thomas
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
next prev parent reply other threads:[~2016-03-19 16:08 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 [this message]
2016-03-19 23:33 ` Yann E. MORIN
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=56ED7967.8050200@mind.be \
--to=arnout@mind.be \
--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