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] [RFCv1 4/4] core: implement per-package SDK and target
Date: Mon, 27 Nov 2017 15:23:07 +0100	[thread overview]
Message-ID: <20171127142307.GG2950@scaer> (raw)
In-Reply-To: <20171125210152.75418592@windsurf.home>

Thomas, Arnout, All,

On 2017-11-25 21:01 +0100, Thomas Petazzoni spake thusly:
> On Sat, 25 Nov 2017 18:30:26 +0100, Arnout Vandecappelle wrote:
> 
> > > Here is how I'm thinking of solving the problem:
> > > 
> > >  - Next to <pkg>_PATCH_DEPENDENCIES, introduce the concept of
> > >    <pkg>_EXTRACT_DEPENDENCIES.  
> > 
> >  _PATCH_DEPENDENCIES is different: it introduces a dependency between foo-patch
> > and bar-patch. Here you want a dependency between foo-extract and tar.

And I think this is a sane approach. We already have such requirements
for tar, lzip and xz.

So we already have three cases where we might want to add an extract
dependency, which is imho sufficient to justify support in the infra.

Besides, having the dependencies managed from the infra will guarantee
the build ordering and the fact that they are built only when required.

> >  So this bit doesn't make sense: _PATCH_DEPENDENCIES are not (necessarily) built
> > before foo-patch. So to be reproducible, it should *not* be rsynced yet.
> > 
> > > 
> > > Thoughts?  
> > 
> >  I'm not at all happy with this approach. It adds generic-package stuff that is
> > used for only one package, and it spreads the logic out over different places.

Quite the opposite: it is used for at least three packages, and it
gathers all the dependencies under the aegis of the package infra.

> >  I'd rather make the logic explicit in dependencies.mk. Something like
> > 
> > ifneq ($(filter host-tar,$(DEPENDENCIES_HOST_PREREQ)),)
> > $(filter-out host-tar,$(DEPENDENCIES_HOST_PREREQ)): host-tar
> > endif
> > 
> > ifneq ($(filter host-ccache,$(DEPENDENCIES_HOST_PREREQ)),)
> > $(filter-out host-tar host-ccache,$(DEPENDENCIES_HOST_PREREQ)): host-ccache
> > endif
> 
> I don't understand how this can work.

TBH, I have a bit of an issue following it as well... :-/

> The big thing to remember is that when I'm building a package, it only
> sees in its per-package host/staging directory the dependencies
> explicitly listed in this package <pkg>_DEPENDENCIES variable.
> 
> With your approach, neither host-tar nor host-ccache are listed in any
> package <pkg>_DEPENDENCIES variable, so the per-package host directory
> of host-ccache and host-tar will never be rsync'ed into the per-package
> host directories of other packages.
> 
> Due to this, the package infrastructure _will_ have to know about the
> fact that all packages depend on host-tar/host-ccache, for the simple
> reason that we need to know that we have to rsync host-tar/host-ccache
> when populating the per-package host directory in the configure step.

I think we should strive at moving as much as possible to packages and
the package infra.

Regards,
Yann E. MORIN.

> 
> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

-- 
.-----------------.--------------------.------------------.--------------------.
|  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:[~2017-11-27 14:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03 16:06 [Buildroot] [RFCv1 0/4] Per-package SDK and target directories Thomas Petazzoni
2017-11-03 16:06 ` [Buildroot] [RFCv1 1/4] pkgconf: use relative path to STAGING_DIR instead of absolute path Thomas Petazzoni
2017-11-07 21:05   ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 2/4] core: change host RPATH handling Thomas Petazzoni
2017-11-05  8:57   ` Yann E. MORIN
2017-11-05 14:44     ` Thomas Petazzoni
2017-11-05 14:48       ` Arnout Vandecappelle
2017-11-07 22:41     ` Thomas Petazzoni
2017-11-07 23:50       ` Arnout Vandecappelle
2017-11-08  8:55         ` Thomas Petazzoni
2017-11-08 10:55           ` Arnout Vandecappelle
2017-11-08 12:30             ` Thomas Petazzoni
2017-11-08 12:38               ` Arnout Vandecappelle
2017-11-07 21:15   ` Arnout Vandecappelle
2017-11-07 21:22     ` Thomas Petazzoni
2017-11-07 23:45       ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 3/4] toolchain: post-pone evaluation of TOOLCHAIN_EXTERNAL_BIN Thomas Petazzoni
2017-11-07 21:23   ` Arnout Vandecappelle
2017-11-07 21:33     ` Thomas Petazzoni
2017-11-07 23:49       ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 4/4] core: implement per-package SDK and target Thomas Petazzoni
2017-11-07 22:50   ` Arnout Vandecappelle
2017-11-07 23:11     ` Thomas Petazzoni
2017-11-07 23:57       ` Arnout Vandecappelle
2017-11-24 14:49         ` Thomas Petazzoni
2017-11-24 14:43     ` Thomas Petazzoni
2017-11-25 17:30       ` Arnout Vandecappelle
2017-11-25 20:01         ` Thomas Petazzoni
2017-11-27 14:23           ` Yann E. MORIN [this message]
2017-11-07 23:21 ` [Buildroot] [RFCv1 0/4] Per-package SDK and target directories 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=20171127142307.GG2950@scaer \
    --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