Buildroot Archive on 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: Sat, 13 Jul 2013 16:07:20 +0200	[thread overview]
Message-ID: <20130713160720.34d850a8@skate> (raw)
In-Reply-To: <CAEYzJUHpYVBAgHnrj73aMwj8pw+p_bScMToM-BSZh3bm--q2gA@mail.gmail.com>

Dear Bj?rn Forsman,

On Fri, 12 Jul 2013 19:07:58 +0200, Bj?rn Forsman wrote:

> > I believe it is much better that Buildroot chokes on a select list of
> > variables, warn about a few others, and accept the rest.
> 
> If you think about it, the downloader is actually a bit different from
> the builder. At some point Buildroot will (like all other build
> systems) grow support for checking each downloaded file against
> checksums specified in the package build file. And once you have that,
> it doesn't really matter how dirty the environment in the *downloader*
> is, because it will be guaranteed to match the checksum, or fail. It
> is only in the *builder* that the environment must be clean.

I am not sure to understand why you separate the download side and the
build side here. Both are done with Buildroot makefiles, there is
nothing different in terms of environment variables between those
steps.

> Are there any reasons for allowing env vars, other than BR2_*, to slip
> through from host and into the Buildroot *builder* processes? I cannot
> think of any.

Yes, we allow passing HOSTCC, UCLIBC_CONFIG_FILE, BUSYBOX_CONFIG_FILE,
and a bunch of other environment variables (see the Buildroot manual).
Also, some environment variables like LD_LIBRARY_PATH or LD_PRELOAD
should just be usable by the user, if he has some funky setup that
requires those environment variables to hold special values.

Best regards,

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-13 14:07 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 [this message]
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

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=20130713160720.34d850a8@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox