Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] JFFS2 / MTD suggestions
Date: Wed, 08 Apr 2009 16:59:11 +0200	[thread overview]
Message-ID: <87ws9vyyww.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <20090408075004.18784e45@surf> (Thomas Petazzoni's message of "Wed\, 8 Apr 2009 07\:50\:04 -0700")

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> Or even better, compile lzo for the host and link against that.

 Thomas> I know that's what we do for automake, autoconf, pkg-config, m4 and a
 Thomas> bunch of other stuff. But I must admit, that personnaly, I'm not
 Thomas> really a fan of this. I would rather prefer to leverage what's
 Thomas> installed on the host, and consider that Buildroot having dependencies
 Thomas> on installed packages (liblzo-dev and others) is normal.

Yes, that works as long as the dependencies are stable and we can work
with the various versions available. That's unfortunately often not
the case, and then the easiest solution is to simply build it
ourselves.

I think lzo clearly fits in the:

 - Not available on most systems
 - Small and hence quick to compile
 - Users (mkfs.jffs2) needs a fairly specific version

Category.

 Thomas> Currently, one of the strong advantage of Buildroot compared
 Thomas> to more heavyweight solutions like OpenEmbedded is that the
 Thomas> time for Buildroot checkout to the first basic root
 Thomas> filesystem being produced is very small (15 minutes or
 Thomas> so). If we start compiling more and more host tools to the
 Thomas> point that we basically recompile everything that's on the
 Thomas> host, we'll to some extent loose this advantage.

True. It's a tradeoff ofcourse, but from looking at various bug
reports we're unfortunately not in a situation today where people can
just download BR on a random machine and run tar jxvf && make
menuconfig && make and expect it to work all the time.

Adding more dependencies on the host is not going to make this any
better.

-- 
Bye, Peter Korsgaard

      reply	other threads:[~2009-04-08 14:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07 15:35 [Buildroot] JFFS2 / MTD suggestions Thomas Petazzoni
2009-04-07 15:57 ` Lloyd Sargent
2009-04-08 13:02   ` Peter Korsgaard
2009-04-07 16:58 ` Cyril HAENEL
2009-04-07 17:13   ` Peter Korsgaard
2009-04-09  8:07     ` Cyril HAENEL
2009-04-09  9:34       ` Peter Korsgaard
2009-04-07 17:02 ` Peter Korsgaard
2009-04-08 14:50   ` Thomas Petazzoni
2009-04-08 14:59     ` Peter Korsgaard [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=87ws9vyyww.fsf@macbook.be.48ers.dk \
    --to=jacmet@uclibc.org \
    --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