All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Makefile: unset MAKEFLAGS
Date: Thu, 11 Jul 2013 15:32:15 +0200	[thread overview]
Message-ID: <20130711153215.3d617c16@skate> (raw)
In-Reply-To: <CAAXf6LUoX1iSW94RREcyOrX1_4QQf1dHFhDmynLoOy18js4fwA@mail.gmail.com>

Dear Thomas De Schampheleire,

On Thu, 11 Jul 2013 13:36:28 +0200, Thomas De Schampheleire wrote:

> dependencies.sh does not complain on the existence of LD_LIBRARY_PATH
> in the environment, only on the presence of the current working
> directory inside of it. But of course, if we decide to unexport this
> variable, then checking its contents is no longer needed.
> Is there any valid use case for someone setting LD_LIBRARY_PATH during
> a buildroot build?

I guess it could be used if someone is building manually some host
tools needed by Buildroot, and a special LD_LIBRARY_PATH is needed to
run such tools. But it really seems like a corner case.

> For the check on the presence of the current working dir in PATH, we
> could question whether it makes sense to raise a message and exit, or
> to manipulate PATH during the build and continue.

True.

> Another variable checked in dependencies.sh is PERL_MM_OPT. This seems
> a good candidate to add to the existing list in Makefile.

Indeed. I'm the one to blame here, I'm the one who added this variable
check in dependencies.sh, if I remember correctly :)

> Is there any particular reason why some unexports are done always, and
> some are done inside a check on BR2_HAVE_DOT_CONFIG ?

So, PKG_CONFIG_PATH, PKG_CONFIG_SYSROOT_DIR and DESTDIR get unset
outside of the BR2_HAVE_DOT_CONFIG conditional, all the other are
inside. I don't really see why we're doing that.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

      reply	other threads:[~2013-07-11 13:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-07 18:42 [Buildroot] [PATCH] Makefile: unset MAKEFLAGS Samuel Martin
2013-07-07 19:38 ` Thomas Petazzoni
2013-07-07 20:09   ` Samuel Martin
2013-07-07 19:58 ` Peter Korsgaard
2013-07-07 20:14   ` Samuel Martin
2013-07-11  9:37 ` Thomas De Schampheleire
2013-07-11 10:33   ` Bjørn Forsman
2013-07-11 11:24     ` Thomas De Schampheleire
2013-07-11 11:46     ` Thomas Petazzoni
2013-07-11 12:02       ` Yann E. MORIN
2013-07-11 12:08         ` Thomas De Schampheleire
2013-07-11 12:17           ` Gustavo Zacarias
2013-07-12 17:07         ` Bjørn Forsman
2013-07-13 14:07           ` Thomas Petazzoni
2013-07-13 14:57             ` Bjørn Forsman
2013-07-11 11:01   ` Thomas Petazzoni
2013-07-11 11:36     ` Thomas De Schampheleire
2013-07-11 13:32       ` Thomas Petazzoni [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=20130711153215.3d617c16@skate \
    --to=thomas.petazzoni@free-electrons.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 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.