Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v7 3/8] core: implement per-package SDK and target
Date: Mon, 31 Dec 2018 15:31:01 +0100	[thread overview]
Message-ID: <20181231153101.387c7d57@windsurf> (raw)
In-Reply-To: <20181230215212.GA24224@scaer>

Hello,

Thanks for the review!

On Sun, 30 Dec 2018 22:52:12 +0100, Yann E. MORIN wrote:

> I don;t have much to propose asa review, except very-minor issues.

Which is good :-) Hopefully I can get some Reviewed-by soon, and merge
this series.

> > There are two main benefits:
> > 
> >  - Packages will no longer discover dependencies that they do not
> >    explicitly indicate in their <pkg>_DEPENDENCIES variable.  
> 
> Note that non-expressed dependencies may still be gathered, if they are
> transitive dependencies.

Yes, of course, but what can we do about this ? It's pretty logical and
obvious that transitive dependencies will be copied, no ?

> > +PER_PACKAGE_DIR := $(BASE_DIR)/per-package  
> 
> Why don't you simply export this variable, like HOST_DIR and TARGET_DIR?
> This would simplify calls to fix-rpath:

Because I generally don't like those global exports. It pollutes the
namespace with some random variable that is really internal to
Buildroot. There is no reason for the build system of all packages to
even see this variable. In fact, I am personally not a big fan of
exporting TARGET_DIR, STAGING_DIR, etc. since they become visible in
packages, and people tend to use them in their package build system,
which is very wrong.

Of course, if the overall consensus is that PER_PACKAGE_DIR should be
exported, I'll do so because I don't want to hold this series just for
this detail.


> > -$(BUILD_DIR) $(BASE_TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST):
> > +$(BUILD_DIR) $(BASE_TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) \
> > +	$(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST) $(PER_PACKAGE_DIR):  
> 
> Don't ident this continuation line, it is misleading: the target of
> the rule appear to be part of the commands.

ACK.

> [--SNIP--]
> > diff --git a/support/scripts/check-host-rpath b/support/scripts/check-host-rpath
> > index c8939569e2..d903a82958 100755
> > --- a/support/scripts/check-host-rpath
> > +++ b/support/scripts/check-host-rpath  
> 
> As I was saying on IRC: when we are not using per-package directories,
> then I was a bit surprised to see that this script (and fix_rpath,
> below) still worked, when the support for PPD is not optional in it.
> 
> What confused me, was that PER_PACKAGE_DIR is always used, even when
> BR2_PER_PACKAGE_DIRECTORIES is unset.
> 
> But as you pointed to on IRC, PER_PACKAGE_DIR is also always defined to
> an non-empty string, that either points to a valid location when
> BR2_PER_PACKAGE_DIRECTORIES=y, or points to a non-existent location
> otherwise.

Yes, I'll add some comments about this.

> 
> > @@ -77,6 +93,7 @@ check_elf_has_rpath() {
> >              dir="$( sed -r -e 's:/+:/:g; s:/$::;' <<<"${dir}" )"
> >              [ "${dir}" = "${hostdir}/lib" ] && return 0
> >              [ "${dir}" = "\$ORIGIN/../lib" ] && return 0
> > +            [[ ${dir} =~ ${perpackagedir}/[^/]*/host/lib ]] && return 0  
>                                             ^^^^^^^
> That would also match the string '//' so maybe we want:
> 
>     ${perpackagedir}/([^/]+/)?host/lib

I'm not sure to understand the ? in ([^/]+/)?. We definitely want one
path component between $(PER_PACKAGE_DIR) and host/lib. So what about:

	${perpackagedir}/[^/]+/host/lib

> > +        if test "${rpath}" != "${changed_rpath}" ; then
> > +            ${PATCHELF} --set-rpath ${changed_rpath} "${file}"  
> 
> Can't you do that unconditioanlly? If it's changed, we need to set it;
> if it's not changed, that set it to the initial value anyway...

There is a reason to do it conditionally: patchelf is slow, you don't
want to run patchelf when you don't need to, and here it's trivial to
know whether it is useful or not to run it. For example, this condition
ensures that people not using per-package directory don't pay the cost
of running all those additional patchelf invocations.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-12-31 14:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-28 10:43 [Buildroot] [PATCH v7 0/8] Top-level parallel build support Thomas Petazzoni
2018-12-28 10:43 ` [Buildroot] [PATCH v7 1/8] support/scripts/check-host-rpath: document existing functions Thomas Petazzoni
2018-12-28 12:47   ` Yann E. MORIN
2019-01-17 21:33   ` Peter Korsgaard
2018-12-28 10:43 ` [Buildroot] [PATCH v7 2/8] Makefile: move definition of TARGET_DIR inside .config condition Thomas Petazzoni
2018-12-28 12:49   ` Yann E. MORIN
2019-01-17 21:35   ` Peter Korsgaard
2018-12-28 10:43 ` [Buildroot] [PATCH v7 3/8] core: implement per-package SDK and target Thomas Petazzoni
2018-12-30 21:52   ` Yann E. MORIN
2018-12-31 14:31     ` Thomas Petazzoni [this message]
2018-12-31 14:45       ` Yann E. MORIN
2019-01-08 18:02   ` Jan Kundrát
2019-11-05 16:38     ` Thomas Petazzoni
2019-11-05 19:05       ` Carlos Santos
2019-11-06  7:57         ` Thomas Petazzoni
2019-11-06  8:13           ` Jan Kundrát
2018-12-28 10:43 ` [Buildroot] [PATCH v7 4/8] Makefile: allow top-level parallel build with BR2_PER_PACKAGE_DIRECTORIES=y Thomas Petazzoni
2018-12-28 12:51   ` Yann E. MORIN
2018-12-28 10:43 ` [Buildroot] [PATCH v7 5/8] package/pkg-generic: make libtool .la files compatible with per-package directories Thomas Petazzoni
2018-12-31  8:44   ` Yann E. MORIN
2018-12-28 10:43 ` [Buildroot] [PATCH v7 6/8] package/pkg-kconfig: handle KCONFIG_DEPENDENCIES " Thomas Petazzoni
2018-12-28 10:43 ` [Buildroot] [PATCH v7 7/8] docs/manual: add details about top-level parallel build support Thomas Petazzoni
2018-12-28 13:03   ` Yann E. MORIN
2018-12-28 13:08     ` Thomas Petazzoni
2018-12-31  8:46       ` Yann E. MORIN
2018-12-28 10:43 ` [Buildroot] [PATCH v7 8/8] docs/manual: document the effect of per-package directory on variables Thomas Petazzoni
2018-12-28 17:21 ` [Buildroot] [PATCH v7 0/8] Top-level parallel build support Thomas Petazzoni
2019-02-22 16:18   ` Andreas Naumann
2019-02-22 18:07     ` Vadim Kochan
2019-02-22 20:29       ` Thomas Petazzoni
2019-02-25  1:10         ` Vadim Kochan
2019-02-25  8:05           ` Thomas Petazzoni
2019-02-25  8:33             ` Vadim Kochan
2019-03-01 14:50             ` Vadym Kochan
2019-03-01 17:18               ` Yann E. MORIN
2019-03-04  7:24                 ` Arnout Vandecappelle
2019-03-04 10:22                   ` Thomas Petazzoni

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=20181231153101.387c7d57@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --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