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] core/pkg-infra: really build all dependencies of foo with foo-depends
Date: Sun, 14 Jul 2019 20:20:06 +0200	[thread overview]
Message-ID: <20190714182006.GF29941@scaer> (raw)
In-Reply-To: <4281e1c1-dda6-5af6-7f0c-4e29cd279922@mind.be>

Arnout, All,

On 2019-07-03 23:28 +0200, Arnout Vandecappelle spake thusly:
> On 02/07/2019 22:12, Yann E. MORIN wrote:
> > Currently, foo-depends only builds build dependencies. This means that
> > download and extract dependencies are not built.
>  But also patch dependencies.
> 
>  Patch dependencies are special, because when used normally, they cause the
> following chain (I'm simplifying, obviously):
> 
> FOO_PATCH_DEPENDENCIES = bar
> foo-patch: bar-patch
> 
> while for all other types of dependencies it would be:
> 
> FOO_EXTRACT_DEPENDENCIES = bar
> foo-extract: bar
> 
>  So, this patch can lead to circular dependencies, because bar could in turn
> depend on foo (that's precisely why this construct was introduced).

Ah, but no, the _PATCH_DEPENDENCIES were not introduced _precisely_ to
allow the inverse _DEPENDENCIES.

_PATCH_DEPENDENCIES were introduced to ensure a package is extracted
before another is patched.

That it allowed for inverted _DEPENDENCIES is totally happenstance. And
I think it was a mistake to not forbid that situation.

>  However, it turns out that we only use this _PATCH_DEPENDENCIES for Linux
> extensions.

And linux-tools.

> In addition, most of them don't even depend back on linux. The only
> one in that situation is RTAI. And even for that case, it's not really a
> circular dependency. Instead, you have:
> 
> linux-depends: rtai <other linux deps>
> rtai: ... linux ...
> linux: linux-install
> linux-install: linux-build
> linux-build: linux-configure
> linux-configure: linux-patch <other linux deps>
> linux-patch: linux-extract rtai-patch
> linux-extract: linux-source
> 
> So, not an actual circular dependency, because 'linux-depends' is not a target
> that is used internally.
> 
>  Therefore, I've applied to master, thanks.
> 
>  I probably should have added the above explanation to the commit message :-(

Well, thanks for the heads-up on this. I was not even expecting it to be
applied so fast, in fact, given the potential for breakage! ;-)

Regards,
Yann E. MORIN.

>  Regards,
>  Arnout
> 
> 
> > First, but a minor point, this is inconsistent with foo-show-depends,
> > which does display all dependencies:
> > 
> >     $ make host-gzip-show-depends
> >     host-skeleton host-tar
> >     $ make host-gzip-depends
> >         # Only host-skeleton is built and installed
> > 
> > Second, and more important, it makes it more difficult to preapre a
> > debug build, like so:
> > 
> >     $ make foo-depends
> >     $ tar cf output.tar output
> >     $ make foo
> >         # bummer, broken
> >         # edit foo.mk to try and fix it
> >     $ rm -rf output; tar xf output.tar
> >         # rince and repeat
> > 
> > Change foo-depends so that it really builds all the dependencies for
> > foo, bringing it on-par with foo-show-depends.
> > 
> > Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > ---
> >  package/pkg-generic.mk | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> > index b00967c648..9620dec524 100644
> > --- a/package/pkg-generic.mk
> > +++ b/package/pkg-generic.mk
> > @@ -801,7 +801,7 @@ $(1)-extract:			$$($(2)_TARGET_EXTRACT)
> >  $$($(2)_TARGET_EXTRACT):	$$($(2)_TARGET_SOURCE)
> >  $$($(2)_TARGET_EXTRACT): | $$($(2)_FINAL_EXTRACT_DEPENDENCIES)
> >  
> > -$(1)-depends:		$$($(2)_FINAL_DEPENDENCIES)
> > +$(1)-depends:		$$($(2)_FINAL_ALL_DEPENDENCIES)
> >  
> >  $(1)-source:		$$($(2)_TARGET_SOURCE)
> >  $$($(2)_TARGET_SOURCE): | $$($(2)_FINAL_DOWNLOAD_DEPENDENCIES)
> > 

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

      reply	other threads:[~2019-07-14 18:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-02 20:12 [Buildroot] [PATCH] core/pkg-infra: really build all dependencies of foo with foo-depends Yann E. MORIN
2019-07-03 21:28 ` Arnout Vandecappelle
2019-07-14 18:20   ` Yann E. MORIN [this message]

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=20190714182006.GF29941@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 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.