[Buildroot] Report from the Buildroot Developer Day

Yann E. MORIN yann.morin.1998 at anciens.enib.fr
Mon Nov 7 19:01:48 UTC 2011


Thomas², All,

On Monday 07 November 2011 13:39:02 Thomas Petazzoni wrote:
> Le Mon, 7 Nov 2011 10:58:22 +0100,
> Thomas De Schampheleire <patrickdepinguin+buildroot at gmail.com> a écrit :
> > One thing I really like about the internal build mechanism is that
> > it's internal. If you want to modify something about it, you can
> > directly patch the code and submit to the list.
> 
> Right. For crosstool-NG you can also patch the code and submit to the
> crosstool-NG list. However I agree that some additional steps are
> needed, but we think that the advantage of factorizing the toolchain
> build problem in crosstool-NG is much stronger than the drawback you're
> mentioning.

Thomas D.S. is right. Currently, the integration of crosstool-NG is not
as smooth as the internal mechanism. This is inherent to the fact that
crosstool-NG is an external program, just like the other tools buildroot
uses (host-ccache, host-gawk, host-automake...)

There are two ways to do a better integration:

1) Include the crosstool-NG menuconfig entries into the buildroot
   menuconfig. This will be difficule for two reasons:
   - namespace clashing [1]
   - maintenance when a newer crosstool-NG version gets integrated

2) Delegate all of the toolchain options down to crosstool-NG, and imagine
   an easy way to display the toolchain (crosstool-NG's) menuconfig to the
   user, either one of:
   - always show after standard menuconfig (cumbersome)
   - document, and tell the user, to run make ctng-menuconfig (that could
     be renamed to toolchainconfig in the end) after mangling the needed
     options (what we do now)
   - enhance kconfig to run commands upon selection from the user [2]

Either way is not really a priority, I guess. The most important thing is
to make the process reliable, and be sure thatcrosstool-NG can safely
replace the internal mechanism for good. Once this is fact, then we can
spend time and effort into making it as smooth as possible for the user.

> > This not only holds for the generation of the toolchain, but also for
> > side-aspects like downloading the necessary tarballs and patching.
> > Since crosstool-ng is treated as a package (at least currently it
> > is), any change you want to make to it, has to be done by adding a
> > patchfile to package/crosstool-ng/. This is much more cumbersome than
> > modifying buildroot files.
> > For example, I added scp support to buildroot some time ago, and use
> > it for the primary download site. When switching to crosstool-ng, this
> > no longer worked, I had to add scp support again.
> > 
> > I think it would be beneficial to buildroot if the integration of
> > crosstool-ng could increase. For example, crosstool-ng using the
> > download mechanisms of buildroot.
> 
> That could be discussed with Yann. I'm not sure how this could work
> practically, though.

From the crosstool-NG side, I had the idea that crosstool-NG could call
to an external program to do the download. Such a program would have
an API like that (not fixed, just a blind shot while writing the mail):
  <dl-program> <basename> <URI [URI ...]>

Then the program would output whatever it wants tos, how many lines it
wants to stdout (so it could be used by crosstool-NG to use as "progress
meter"), and print on the last line the absolute path where the tarball
was put.

On the buildroot side, I am not sure at all what could be done. Currently,
tarballs are downloaded because of Makefile dependencies. But in that case
there is no dependency at all, so it would be kind of weird to do it...
Maybe something along the lines of:
  make ext-download BASE=basename URI_LIST="list of URI"

The 'ext-download' rule would leverage the internal download helpers.
Then the program to use would be simply:
  #!/bin/sh
  set -e
  base="$1"; shift
  make BASE="${base}" URI_LIST="$*"
  printf "%s/%s" "${DL_DIR}/${base}"

Not too sure that would be nice enough, though...

> > Great, I hope to be able to join this time.
> Great!

Yes, indeed, that'd be nice to see others join in!


[1] I was thinking about enhancing kconfig to handle namespaces, such as:
      namespace FOO
      config bar
        bool "bar"
      endnamespace
    which would yield the following option (given the generic CONFIG_
    prefix, which could be seen as the top-level namespace):
      CONFIG_FOO_BAR

   But that's not easy to implement, and even less easy to use. Deriving
   a variable name only from the 'config' line would be complex and
   error-prone. There are many corner cases, eg.:
   - Wopuld it be valid to use the short name if refering to an option in
     the same namespace (eg. "depends on FOO_BAR" or "depends on BAR")?

[2] I've thought about something like for a long time now, to serve two
    purposes:
    - run a program to do various stuff
    - run a program to add/remove config options on the fly

  The first would allow to, for example, run secondary menuconfigs:
    config FOO
      action_TYPE "program arg1" ARG2_IS_A_CONFIG_OPTION "arg3"

  where TYPE could be:
    void  : the result of the program is consigned to oblivion
    bool  : set if program succeeds, unset otherwise
    int   : set to the program error-code (or its stdout?)
    string: the stdout of the program is affected to FOO

  The second could be used to add/remove secondary menuconfigs, but would
  probably require something like the namespace above. Anyway, someting
  like:
    menuconfig FOO
      action_include "program args..."

  then, when FOO is set, program is run, its output parsed as config
  options that are added to the current namespace. When FOO is unset
  program is run and its output interpreted as config options to remove
  from the current namespace. That will be *very* hard to do... :-/

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'



More information about the buildroot mailing list