All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] system: add option to pass extra args to post-build and post-image scripts
Date: Wed, 10 Jul 2013 18:17:28 +0200	[thread overview]
Message-ID: <20130710161728.GA3297@free.fr> (raw)
In-Reply-To: <20130710091628.1d01d59c@skate>

Thomas, All,

On 2013-07-10 09:16 +0200, Thomas Petazzoni spake thusly:
> On Tue, 9 Jul 2013 20:35:05 +0200, Yann E. MORIN wrote:
> > This was refused (and rightfully) as that would greatly impact users
> > depending on the current behaviour, and some alternate solution were
> > proposed:
> >   - have a single script that would behave differently on how it sould
> >     be called, and have different symlinks pointing to that script;
> >   - have a script for each configuration, that 'sources' a functions
> >     file and call the required functions
> > 
> > After playing a bit with both solutions, it turned out to be not
> > entirely manageable, especially when the inrastructure put in place by
> > the functions changes, since all scripts must be changed accordingly.
> 
> I am not quite sure to understand why the symlink solution doesn't work
> in your case. Could you elaborate on that?

The basic idea behind usig a symlink is that:
  - there is a single script with all the infrastructure
  - the script decides what to do based on ${0}

The script I'm using has no board-specific parts, only a handfull
generic functions, and parses a board-specific file that describes what
to do.

So instead of a single file (the board description for that project), I
need two: the symlink which will never change, and the board file.

Since the symlink will never change, it is just lying there for no
reason.

For a few boards/projects, using a symlink can be enough, but as I will
eventually be managing a few dozens, or even more, boards/projects, I'd
end up with as many symlinks that serve no purpose except working around
a limitation in Buildroot, limitation which can be easily raised in a
backward-compatible way.

Being able to pass a argument to the script means I have a single file
to manage per board/project, and not carry this useless symlink.

> Regarding the patch itself, I'd say why not. I'm just wondering if it
> wouldn't be better to have separate arguments for both scripts. Not
> sure.

That was my original idea, too, but as an afterthought I decided not to,
since the argument(s) passed will probably be something like the board
and the project name (eg. ( rpi/tvheadend ) or ( rpi, tvheadend )), and
that would be common to the postbuild/image scripts.

But I have no strong opinion on this. Copy-pasting between each option
will be easy enough! ;-) I can upgrade the infra to separate both if Peter
and you want it.

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.  |
'------------------------------^-------^------------------^--------------------'

  parent reply	other threads:[~2013-07-10 16:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-09 18:06 [Buildroot] [PATCH] system: add option to pass extra args to post-build and post-image scripts Yann E. MORIN
2013-07-09 18:25 ` Baruch Siach
2013-07-09 18:54   ` Yann E. MORIN
2013-07-09 18:35 ` Yann E. MORIN
2013-07-09 21:50   ` Peter Korsgaard
2013-07-10  7:16   ` Thomas Petazzoni
2013-07-10  9:29     ` Thomas Petazzoni
2013-07-10  9:53       ` Peter Korsgaard
2013-07-10 12:49         ` Thomas Petazzoni
2013-07-10 16:22           ` Yann E. MORIN
2013-07-10 16:17     ` Yann E. MORIN [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-07-09 22:00 Yann E. MORIN
2013-07-10  7:31 ` Peter Korsgaard

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=20130710161728.GA3297@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 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.