All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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 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.