From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Some topics for the Buildroot Developer Day
Date: Mon, 24 Oct 2011 17:38:15 +0200 [thread overview]
Message-ID: <20111024173815.2277c6dd@skate> (raw)
Hello,
As discussed on IRC, I am posting below a list of topics that might be
discussed during the developer day. Note that this is just _my_ list of
topics, note the one of the Buildroot project as a whole. Moreover,
it's very likely that not all topics will be covered during our meeting
day. However, feel free to add your opinion and/or your additional
topics, especially if you can't make it to the Developer day.
Regards,
Thomas
ELCE 2011 meeting agenda
========================
* Migration to the Ascii-doc format, what remains to be done ?
Infrastructure on the web server side ?
* Extract sources in a new output/sources/ directory, and do
out-of-tree build of packages.
Pros:
- Allows more natural integration with the override source
directory mechanism. No rsync needed here, especially useful for
big packages such as the kernel.
- Allows to extract only once the source code for utitilies built
for the host and the target (X.org components, Glib/Gtk stack,
etc.)
- Should work fine for all CMake-based and autotools-based packages.
Cons:
- Not all packages support out-of-tree build. The infrastructure
should support a <pkg>_OUTOFTREE boolean, defaulting to NO for
all packages, overriden to YES for autotools-based and
CMake-based packages. When set to NO, the infrastructure will
have to copy/rsync the source code to the build directory. This
adds an additional copy of the source code for packages that
don't support out-of-tree build.
* Website improvement. The website is ugly, never changes, not
representative of the vivacity of the community. At least improve
the design. Wiki ? Blog ?
* Maintainance/patch review/merge. How to spread the load ? Should we
move to a model with trusted maintainers for specific parts of
Buildroot ? Usage of patchwork/Gerrit ?
* Host packages visible in menuconfig. Discussion has taken place on
the list, consensus reached between several contributors,
implementation proposed. What do we do ?
+ proposal of Arnout to derive host dependencies from target
dependencies.
* Per-package device files handling, proposed by Maxime Ripard.
* Testing infrastructure. Possible to put build results on the Web
server ? Common format for them ?
* Tracking of files installed by packages. Do we care ? Is this an
important feature of Buildroot ? Won't the added complexity make
Buildroot more complicated to understand ?
Which solution ? Two solutions:
- Change the installation steps of packages so that each package
installs in a different directory.
Pros:
seems to be the cleanest solution.
allows to easily detect packages overriding files installed by
other packages.
Cons:
requires modifications of all gentargets packages to use
$$(STAGING_DIR) and $$(TARGET_DIR) instead of $(STAGING_DIR)
and $(TARGET_DIR).
strange handling of host packages. DESTDIR isn't used, the
prefix is the absolute path to HOST_DIR.
- Keep installing package files in their normal directory, but
detect new files and modified files.
Pros:
no need to change anything in the current package installation
procedures.
Cons:
need to scan the TARGET_DIR, STAGING_DIR and HOST_DIR after
every package installation.
hard to detect modified/overwritten files, except by storing
hashes of installed files.
* Next big directions. What are the next big directions for Buildroot
? The major features we want to implement ?
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next reply other threads:[~2011-10-24 15:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-24 15:38 Thomas Petazzoni [this message]
2011-10-24 16:59 ` [Buildroot] Some topics for the Buildroot Developer Day Robert Schwebel
2011-10-24 19:47 ` Thomas Petazzoni
2011-10-24 20:06 ` Eric Bénard
2011-10-25 6:02 ` Peter Korsgaard
2011-10-25 6:34 ` Robert Schwebel
2011-10-25 7:15 ` Peter Korsgaard
2011-10-25 12:20 ` Robert Schwebel
2011-10-24 21:44 ` Shawn J. Goff
2011-10-25 5:53 ` Mike Frysinger
2011-10-24 22:54 ` Quotient Remainder
2011-10-25 6:24 ` Thomas Petazzoni
2011-10-25 7:13 ` Peter Korsgaard
2011-10-25 8:26 ` Thomas De Schampheleire
2011-10-26 12:48 ` Yegor Yefremov
2011-10-26 13:05 ` Gustavo Zacarias
2011-10-29 6:20 ` Thomas Petazzoni
2011-10-29 11:36 ` Gustavo Zacarias
2011-11-18 16:48 ` Thomas Petazzoni
2011-10-30 20:29 ` 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=20111024173815.2277c6dd@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