[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Thomas Petazzoni]

Hello,

A Buildroot Developer Day took place last month, on Friday 29th
October, right after the Embedded Linux Conference Europe. The people
who participated to the session are :

 * Peter Korsgaard
 * Lionel Landwerlin
 * Yann E. Morin
 * Nicolas Ferre (only the morning)
 * Patrice Vilchez (only the morning)
 * Thomas Petazzoni

This is a personal report from Thomas Petazzoni. It hasn't been
reviewed by the other participants, so they are kindly invited to
share their thoughts and corrections.

Board cleanup
=============

Since Nicolas Ferre and Patrice Vilchez from Atmel were only present
for the morning, we discussion started by a presentation for Thomas
Petazzoni on his board cleanup work.

The board cleanup work current status is available at:
  http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=for-2011.02/boards-cleanup

The goal is to cleanup the contents of the target/device directory and
generally simplify how board support works in Buildroot. This is done
by:

 * Using more kernel defconfigs instead of Buildroot specific kernel
   configuration

 * Using more recent versions of the kernel and bootloader

 * Using patches available on the Web instead of patches integrated
   into the Buildroot source tree (for kernel/U-Boot)

 * Using minimal Buildroot defconfig and minimal kernel defconfig, to
   significantly reduce the size of the configuration files

 * Reducing the number of target skeleton. Instead of having separate
   target skeleton each time a minor modification is needed, the
   long-term idea is to add more options in Buildroot to tune the
   target skeleton. For exemple, when one wants to use mdev instead of
   a simple static /dev directory

The target/device directory is now mostly empty. Board-specific stuff
is now located in board/<manufacturer>/<board>.

Nicolas and Patrice, who ship Buildroot as one of the development
environment for the AT91 Atmel evaluation boards, were generally
satisfied with those changes.

They however, proposed some improvements:

 * Add the ability for some key components (kernel, u-boot, etc.) to
   specify a patch that is in fact a tarball containing multiple
   patches, stored on http/ftp. This is more practical than the
   current situation of a single file patch, since most of the time,
   series of patches needs to be applied.

 * Add the ability to specify a space-separated list of patches.

Thomas has voluntered to implement those two changes for the 2011.02
release.

Libtool issue
=============

As Lionel Landwerlin was here, we also quickly summarized the state of
the libtool issue. For the record, the problem is that libtool 1.x and
2.2 do not support sysroot correctly, so the .la files must be patched
to include an absolute path to the staging directory.

This isn't a very nice solution, and Lionel proposed on the list to
patch libtool to fix the problem and then autoreconfigure all packages
using libtool. Unfortunately, this would significantly increase the
build time and would be probably be difficult to achieve for some
packages. For that reason, we have kept the existing solution and just
extended it for libtool 2.2 (only libtool 1.x was supported at that
time). This was all done before the meeting.

Libtool 2.4 finally fixes the sysroot problem. So the general
consensus was that we should keep the current hack for the current
packages, and hope for the migration to libtool 2.4 to gradually
happen, reducing the problem progressively.

Crosstool-NG integration
========================

There was a quick summary of the Crosstool-NG integration done by Yann
E. Morin. Peter was generally satisfied with this initial integration,
but wanted to see the IPv6/RPC/locale/etc. options propagated to
Crosstool-NG configure/build process. Yann agreed that this is lacking
from the current integration, but he plans to work on this on the
future. It shouldn't raise any major design issue.

Peter's goal is to gradually replace the Buildroot internal process to
build toolchains by Crosstool-NG. He currently imagines a one-year
timeframe before phasing out the Buildroot internal process.

Toolchain cleanup
=================

The next topic discussed was the cleanup of the toolchain build
process.

Currently, the cross-compiling toolchain generated by Buildroot is
installed in $(STAGING_DIR) (both the toolchain binaries and the
toolchain sysroot). This means that $(STAGING_DIR) contains both
target binaries and host binaries (the ones of the toolchain). We
currently advise users to add $(STAGING_DIR)/usr/bin to their PATH to
get access to the toolchain, but this means that they also get some
target-specific binaries in their PATH, which isn't good.

So, we agreed on :

 * Toolchain components should be built in $(BUILD_DIR) and not inside
   a specific $(TOOLCHAIN_DIR) directory

 * The toolchain should be installed in $(HOST_DIR), with binaries in
   $(HOST_DIR)/usr/bin and its sysroot in
   $(HOST_DIR)/usr/<tuple>/sysroot/

 * Make $(STAGING_DIR) a symbolic link to
   $(HOST_DIR)/usr/<tuple>/sysroot, so that libraries/headers gets
   installed here. $(HOST_DIR) will therefore contain everything
   that's needed to build applications for the target: both host
   utilities, target utilities, libraries and headers.

Gustavo Zacarias has already started the implementation of this first
part. The current status of this work is available from
git://repo.or.cz/buildroot-gz.git (branch toolchain-rework), but it is
not yet finalized nor ready.

The external toolchain support would also be modified to copy the
external toolchain sysroot into $(HOST_DIR)/usr/<tuple>/sysroot.

Then, we would add the feature of generating a SDK from
Buildroot. First in a simple way :

 * Turn the STAGING_DIR kconfig option into a "SDK path" option, and
   use it as the host dir. It's therefore the responsability of the
   user to select upfront where the SDK will be located. Buildroot
   build process will properly install things in there, and have all
   paths (rpath, libtool paths) adjusted correctly.

 * Install into the SDK a small shell script that SDK users can
   source. This shell script would set the PATH, PKG_CONFIG_PATH,
   PKG_CONFIG_SYSROOT_DIR environment variables to the appropriate
   values.

The goal of such SDK is to solve the following common use case. In a
company, a team of people is responsible of embedded Linux integration
using Buildroot. This team has all the skills on how to run/use
Buildroot. Another team is the application development team, and they
don't want/don't know how to use Buildroot. The first team should just
provide them a toolchain with all libraries/headers needed to build
their application and run/debug it on the target. This is the goal of
the SDK.

Later on, we could improve this by making the SDK relocatable. The
"SDK path" option would no longer be needed. A "make sdk" target would
be added to generate a tarball containing the SDK. But since some
files (notably .la files) contain absolute paths, an installation
script would be generated inside this tarball, so that users can
execute this script to install the SDK.

Top-level parallel make
=======================

One of the idea we tried to reduce the build time was the
autoconf configuration cache shared by all packages. Unfortunately,
due to subtle differences between the configure checks of different
packages, this solution turned out not to be reliable.

Therefore, Thomas Petazzoni has started experiments to make top-level
parallel make work (i.e be able to use "make -j4" directly). This
would allow several packages to be downloaded, extracted, configured
and built simultaneously. Nothing is ready for testing yet, but Thomas
wanted to inform the other developers of this effort.

Package management
==================

Lionel Landwerlin has started working on package management for some
time now. The current status of this work is visible at
http://git.potipota.net/cgi-bin/cgit.cgi/buildroot/log/?h=package-generation.

What Lionel's work is doing is :

 * It overrides STAGING_DIR, TARGET_DIR and HOST_DIR on a per-package
   basis to install each package staging, target and host files into a
   separate directory.

 * Tarball those directories in order to keep track of which package
   installed what files

 * Extract those tarballs into the STAGING_DIR, TARGET_DIR and
   HOST_DIR in order to preserve the current behaviour.

For the moment, the goal is not yet to generate packages, but rather
to know what each package installed. Lionel has also fixed various
minor issues due to packages not creating all necessary directories in
STAGING_DIR/TARGET_DIR, making assumptions on them being created by
previous packages.

We discussed what should be the next steps of this work. The following
notes documents the TODO-list :

 * Implement <pkg>-uninstall in the following way:

    - Removes files of the package from STAGING_DIR, TARGET_DIR and
      HOST_DIR

    - Removes installation stamp files so that next time one runs
      "make" the package gets reinstalled to STAGING_DIR, TARGET_DIR
      and HOST_DIR

    - <pkg>-uninstall is not recursive: it does not take care of
      packages that depend on the package being uninstalled.

 * Implement <pkg>-clean in the following way:

    - Do <pkg>-uninstall

    - Remove the source/build directory of the package, so that next
      time run is make, the package is re-extracted, re-patched,
      re-configured, re-built, etc.

    - <pkg>-clean is not recursive: it does not take care of packages
      that depend on the package being uninstalled.

Once this is done, the $($(PKG)_CLEAN_CMDS),
$($(PKG)_UNINSTALL_STAGING_CMDS) and $($(PKG)_UNINSTALL_TARGET_CMDS)
should be removed from all packages: the new mechanism will allow to
more reliably remove all packages.

Once this is done, the idea is to add a new <pkg>-remove target that
removes the package and all its reverse depencies (i.e the packages
depending on it) automatically. For that, after the configuration of a
given package, add the package name into the reverse dependencies
files for each package it depends on. The reverse dependency files
would be $(STAMP_DIR)/.<pkg>.rdeps, with one reverse dependency per
line.

Then, <pkg>-remove would be implemented as follow:

 * Remove files from STAGING_DIR, TARGET_DIR and HOST_DIR using the
   tarballs created for the package at install time

 * Call the <pkg>-remove target of all reverse dependencies (beware of
   duplicate reverse dependencies)

 * Remove the reverse dependency file

 * Remove the install stamps of the current package

Finally, in order to automatically remove packages that are no longer
selected in the configuration (this is the *REAL* goal of all this
work), the <pkg>-remove target should be added to the
$(TARGETS_TO_CLEAN) variable for each non-selected package. In the
top-level Makefile, we would run all targets in $(TARGETS_TO_CLEAN)
before running the targets in $(TARGETS). Therefore, all unselected
packages would be removed.

Lionel Landwerlin has voluntered to progress on this work.

Conclusion
==========

This Developer Day has been very productive in terms of discussion,
and for some complicated topics, we know have a better understanding
on what should be implemented and how it should be implemented. The
participants were all very satisfied of the day spent discussing
Buildroot future.

The next Buildroot Developer Day will happen on Monday, 7th February
2011 in Brussels, Belgium. This is just after the FOSDEM conference
(http://www.fosdem.org). Interested participants are invited to
contact Peter Korsgaard and Thomas Petazzoni.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Yann E. MORIN]

Thomas, All,

On Tuesday 23 November 2010 22:14:17 Thomas Petazzoni wrote:
> A Buildroot Developer Day took place last month, on Friday 29th
> October, right after the Embedded Linux Conference Europe.
[--SNIP--]
> This is a personal report from Thomas Petazzoni. It hasn't been 
> reviewed by the other participants, so they are kindly invited to
> share their thoughts and corrections.

Thank you Thomas, it's all good from my PoV.

[--SNIp--]
> Crosstool-NG integration
> ========================
> 
> There was a quick summary of the Crosstool-NG integration done by Yann
> E. Morin. Peter was generally satisfied with this initial integration,
> but wanted to see the IPv6/RPC/locale/etc. options propagated to
> Crosstool-NG configure/build process. Yann agreed that this is lacking
> from the current integration, but he plans to work on this on the
> future. It shouldn't raise any major design issue.

Basically, I have issues (none that can't be fixed or worked around)
because of the way options a recurrently handled in Buildroot and
crosstool-NG.

For example, Buildroot has options for IPv6 and wide-chars that are used
to tweak uClibc's configuration.

In crosstool-NG, there is an option for wide-chars, and it is pushed down
to uClibc's config. But for IPv6, it is the responsibility of the user to
pass a properly prepared .config file.

(Of course, IPv6 and wchar are not the only options, they are here only
to illustrate the issue).

So there are to possibilities:
1) add those options to crosstool-NG
2) have dedicated code in Buildroot to munge crosstool-NG's uClibc's .config
   (yes, the .config for uClibc used by crosstool-NG)

Of course, 1) would be the best way, but may not happen soon enough.
OTOH, 2) makes the code a little bit uggly in Buildroot (but that is
manageable) and we will be able to resort to 1) when it is implemented.

Well, I plan to push a few patches by the end of the WE that will
implement a few of the major options.

> Peter's goal is to gradually replace the Buildroot internal process to
> build toolchains by Crosstool-NG. He currently imagines a one-year
> timeframe before phasing out the Buildroot internal process.

I believe this is a little bit optimistic. What I would say is that in
a year time, we can switch the _default_ to being to use crosstool-NG,
but still have the internal mechanism as a backup. Then, I think that
another 6 months will be needed before we can decide to get rid of the
internal mechanism altogether.

Do not forget that for now, crosstool-NG does not support the same set
of architectures Buildroot does. Also, Buildroot has per-arch patchsets
which is (for now at least) a no-no in crosstool-NG.

[--SNIP--]
> Conclusion
> ==========
> 
> This Developer Day has been very productive in terms of discussion,
> and for some complicated topics, we know have a better understanding
> on what should be implemented and how it should be implemented. The
> participants were all very satisfied of the day spent discussing
> Buildroot future.

And we add good ${BEVERAGE[@]} and ${LUNCH} in a pretty nice ${PLACE}.

> The next Buildroot Developer Day will happen on Monday, 7th February
> 2011 in Brussels, Belgium. This is just after the FOSDEM conference
> (http://www.fosdem.org). Interested participants are invited to
> contact Peter Korsgaard and Thomas Petazzoni.

Hehe. FOSDEM `11 is coming fast... I'll sure be there!

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

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@anciens.enib.fr> writes:

Hi,

 >> This is a personal report from Thomas Petazzoni. It hasn't been 
 >> reviewed by the other participants, so they are kindly invited to
 >> share their thoughts and corrections.

 Yann> Thank you Thomas, it's all good from my PoV.

Here as well.

 Yann> So there are to possibilities:
 Yann> 1) add those options to crosstool-NG
 Yann> 2) have dedicated code in Buildroot to munge crosstool-NG's uClibc's .config
 Yann>    (yes, the .config for uClibc used by crosstool-NG)

2 is fine by me (we do the same thing for the internal
toolchain). Perhaps we could even reuse the config handling in
toolchain/uClibc/uclibc.mk ?

 >> Peter's goal is to gradually replace the Buildroot internal process to
 >> build toolchains by Crosstool-NG. He currently imagines a one-year
 >> timeframe before phasing out the Buildroot internal process.

 Yann> I believe this is a little bit optimistic. What I would say is that in
 Yann> a year time, we can switch the _default_ to being to use crosstool-NG,
 Yann> but still have the internal mechanism as a backup. Then, I think that
 Yann> another 6 months will be needed before we can decide to get rid of the
 Yann> internal mechanism altogether.

True.

 Yann> Do not forget that for now, crosstool-NG does not support the same set
 Yann> of architectures Buildroot does. Also, Buildroot has per-arch patchsets
 Yann> which is (for now at least) a no-no in crosstool-NG.

Do you refer to the avr32 stuff or something else?

 >> The next Buildroot Developer Day will happen on Monday, 7th February
 >> 2011 in Brussels, Belgium. This is just after the FOSDEM conference
 >> (http://www.fosdem.org). Interested participants are invited to
 >> contact Peter Korsgaard and Thomas Petazzoni.

 Yann> Hehe. FOSDEM `11 is coming fast... I'll sure be there!

Great!

-- 
Bye, Peter Korsgaard

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Sam Ravnborg]

On Tue, Nov 23, 2010 at 10:14:17PM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> A Buildroot Developer Day took place last month, on Friday 29th
> October, right after the Embedded Linux Conference Europe. The people
> who participated to the session are :
> 
>  * Peter Korsgaard
>  * Lionel Landwerlin
>  * Yann E. Morin
>  * Nicolas Ferre (only the morning)
>  * Patrice Vilchez (only the morning)
>  * Thomas Petazzoni
> 
> This is a personal report from Thomas Petazzoni. It hasn't been
> reviewed by the other participants, so they are kindly invited to
> share their thoughts and corrections.

Thought this was a nice write-up so I forwarded it to lwn.net.
It is in their "Development" page for this weeks edition.
Requires subscription to see it until next Thursday.

	Sam

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Thomas Petazzoni]

On Thu, 25 Nov 2010 18:21:29 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:

> Thought this was a nice write-up so I forwarded it to lwn.net.
> It is in their "Development" page for this weeks edition.
> Requires subscription to see it until next Thursday.

Thanks for doing this!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Peter Korsgaard]

>>>>> "Sam" == Sam Ravnborg <sam@ravnborg.org> writes:

Hi,

 Sam> Thought this was a nice write-up so I forwarded it to lwn.net.  It
 Sam> is in their "Development" page for this weeks edition.  Requires
 Sam> subscription to see it until next Thursday.

Thanks!

-- 
Bye, Peter Korsgaard

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Thomas De Schampheleire]

Hi,

On Tue, Nov 23, 2010 at 10:14 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[...]
>
> Board cleanup
> =============
>
[...]
>
> Nicolas and Patrice, who ship Buildroot as one of the development
> environment for the AT91 Atmel evaluation boards, were generally
> satisfied with those changes.
>
> They however, proposed some improvements:
>
> ?* Add the ability for some key components (kernel, u-boot, etc.) to
> ? specify a patch that is in fact a tarball containing multiple
> ? patches, stored on http/ftp. This is more practical than the
> ? current situation of a single file patch, since most of the time,
> ? series of patches needs to be applied.
>
> ?* Add the ability to specify a space-separated list of patches.
>
> Thomas has voluntered to implement those two changes for the 2011.02
> release.

What about allowing components to be located in a separate location,
outside of buildroot?

For example, I currently have a custom linux kernel, that I would like
to use in buildroot. I selected the 'custom' kernel options, and
placed the .tar.bz2 file containing the custom kernel in the 'dl'
directory of buildroot. This works.

Unfortunately, since the custom kernel is under development, I
regularly need to make changes to it. My current approach forces me to
create a new .tar.bz2 archive every time I want to create a build with
the changed kernel.

Another solution would be to create patches each time I create a
build, and specify the patches in buildroot (using one of the proposed
improvements above), but still it requires me to do manual work.

It would be interesting to have a feature that allows one to specify a
path to an (unpacked) kernel. Buildroot would then directly use this
path as the source base, but would place the output files elsewhere
(in the output directory of buildroot).
Each time I modify the sources, buildroot should automatically (and
this is the hard part) determine it should rebuild them, but I don't
need to manually create an archive or patches.

Thanks,
Thomas

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Thomas Petazzoni]

Hello,

On Fri, 26 Nov 2010 13:16:45 +0100
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> wrote:

> What about allowing components to be located in a separate location,
> outside of buildroot?
> 
> For example, I currently have a custom linux kernel, that I would like
> to use in buildroot. I selected the 'custom' kernel options, and
> placed the .tar.bz2 file containing the custom kernel in the 'dl'
> directory of buildroot. This works.
> 
> Unfortunately, since the custom kernel is under development, I
> regularly need to make changes to it. My current approach forces me to
> create a new .tar.bz2 archive every time I want to create a build with
> the changed kernel.
> 
> Another solution would be to create patches each time I create a
> build, and specify the patches in buildroot (using one of the proposed
> improvements above), but still it requires me to do manual work.
> 
> It would be interesting to have a feature that allows one to specify a
> path to an (unpacked) kernel. Buildroot would then directly use this
> path as the source base, but would place the output files elsewhere
> (in the output directory of buildroot).
> Each time I modify the sources, buildroot should automatically (and
> this is the hard part) determine it should rebuild them, but I don't
> need to manually create an archive or patches.

Actually Mike Frysinger has recently proposed a patch that does exactly
this for the Linux kernel, so you may want to have a look at it and see
if it works for you.

I completely agree with this feature, but before including Mike's
patch, I'd like to see if it's possible to make it more generic. This
problem is not only true for the kernel, it is also true for the
user-space packages as well. It'd be nice if for some packages, it was
possible to point Buildroot to a source tree, to make it easy to work
on those packages (like when you're developing/fixing bugs in an
application or library).

The topic was shortly raised this morning on the IRC channel, but no
clear solution was found yet. Input, feedback and ideas on the matter
are definitely appreciated.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Yann E. MORIN]

Thomas & Thomas, All,

On Friday 26 November 2010 14:45:10 Thomas Petazzoni wrote:
> On Fri, 26 Nov 2010 13:16:45 +0100
> Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> wrote:
> > What about allowing components to be located in a separate location,
> > outside of buildroot?
[--SNIP--]
> The topic was shortly raised this morning on the IRC channel, but no
> clear solution was found yet. Input, feedback and ideas on the matter
> are definitely appreciated.

I did not follow the IRC log, but here's my suggestion...

Add a config knob where the user can enter the path to a directory.
That directory is expected to contain packages in sub-directories,
the way we currently have in package/ in Buildroot. Then, for each
package that is present there, we use it instead of our own version.

The Linux kernel, the bootloaders is special, as it is not in package/, but that can
probably be handled.

Of course, that's not currently trivial to implement (it might even
be completely impossible the way we currently include packages), but
it can be worth investigating...

Well, my 2 cents... ;-)

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

[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

[Thomas De Schampheleire]

Hi,

On Sat, Nov 27, 2010 at 12:23 AM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Thomas & Thomas, All,
>
> On Friday 26 November 2010 14:45:10 Thomas Petazzoni wrote:
>> On Fri, 26 Nov 2010 13:16:45 +0100
>> Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> wrote:
>> > What about allowing components to be located in a separate location,
>> > outside of buildroot?
> [--SNIP--]
>> The topic was shortly raised this morning on the IRC channel, but no
>> clear solution was found yet. Input, feedback and ideas on the matter
>> are definitely appreciated.

First of all, I agree that this should be a generic feature for any
package, rather than for the kernel (or a limited list of packages)
only.

>
> I did not follow the IRC log, but here's my suggestion...
>
> Add a config knob where the user can enter the path to a directory.
> That directory is expected to contain packages in sub-directories,
> the way we currently have in package/ in Buildroot. Then, for each
> package that is present there, we use it instead of our own version.

Such a configuration option has the advantage of not needing to add a
new configuration option for each individual package.
A similar idea seems to be presented on IRC
http://ibot.rikers.org/%23uclibc/20101126.html.gz

Whatever way the external path is specified, it is still unclear to me
how we'll be able to tell whether the external source has changed
since the last 'make'. Ideally, there would be some form of automatic
detection.

One way is to just let the package make handle it (let make detect
whether a target is up to date), but this has the disadvantage of
having to call the package make unconditionally, which adds to build
time.

Another solution is to force users to indicate which external sources
have changed. Either by touching a special file, or by explicitly
calling a rebuild-target. Of course, this is error-prone and not so
user-friendly.

Are there other options?

Best regards,
Thomas