[Buildroot] Stuff for the next release (2010.11)

[Buildroot] Stuff for the next release (2010.11)

[Thomas Petazzoni]

Hello,

Just in order to avoid any duplication of work, here's what I've
started to work on for 2010.11, the future Buildroot release (once
2010.08 is released by the end of this month by Peter) :

 * Clean up all the target/device mess

   The general idea is that there will no longer be any configuration
   option for each particular board. Instead, we will just use
   defconfig files for each board that we support.

   The defconfig files will be minimized. Instead of having values for
   all options, only the non-default values will be stored. So
   basically, for a board defconfig, this boils down to: architecture
   definition, bootloader configuration and kernel configuration. Even
   the set of packages will not be considered part of a board defconfig
   (since a particular board can be used for various applications,
   requiring different set of packages).

   The support for all supported boards will be cleaned up and updated,
   with the goal of minimizing the number of kernel patches and target
   skeletons we are carrying.

   A new directory, boards/ will replace target/device. It will be used
   to store kernel and bootloader patches, or target skeletons.

 * Removed the mini_device_table thing.

 * Updated the package/config to 2.6.36-rc1. I'll update it to the
   final 2.6.36 when it's available.

   To do so, I've cleaned up the update process for package/config.
   Instead of a single big kconfig-to-buildroot2.patch (which nobody
   was keeping up-to-date anyway), I've created a Quilt stack of
   patches. It allowed to ease the transition from 2.6.30 to 2.6.36-rc1.

   The goal of upgrading to 2.6.36-rc1 was to benefit from the recent
   'savedefconfig' thing, which creates a minimal defconfig file.

The progress of this work can be seen at
http://git.buildroot.net/~tpetazzoni/git/buildroot/log/?h=boards-cleanup.
Of course, this is all work in progress, but your comments are very
welcome.

Thanks,

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

[Buildroot] Stuff for the next release (2010.11)

[Sam Ravnborg]

>  * Updated the package/config to 2.6.36-rc1. I'll update it to the
>    final 2.6.36 when it's available.
> 
>    To do so, I've cleaned up the update process for package/config.
>    Instead of a single big kconfig-to-buildroot2.patch (which nobody
>    was keeping up-to-date anyway), I've created a Quilt stack of
>    patches. It allowed to ease the transition from 2.6.30 to 2.6.36-rc1.

For the record we are working on making the integration
easier for non-kernel projects utilizing kconfig.

In headlines that is:
- Make CONFIG_ prefix configurable at buildtime
  Basically adding -DCONFIG_=BR2_ will do the trick

- Use mainmenu entry as headline in the frontends

- Drop "kernel" from all help texts
  So there is no longer any "kernel" texts hardcoded

I guess a few other nits I forgot.

I hope this is merged in next merge window - but no promises.

The objective is that external users like buildroot no
longer need to carry any patched to use kconfig.
We will _not_ meet this objective at next merge window,
but I hope we will be rather close.

	Sam

[Buildroot] Stuff for the next release (2010.11)

[Thomas Petazzoni]

Hello Sam,

On Sat, 21 Aug 2010 19:36:33 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> For the record we are working on making the integration
> easier for non-kernel projects utilizing kconfig.

Yes, I've followed parts of the discussion about this, and that's very
good news. I think other projects, such as Crosstool-NG, Busybox,
PTXdist, uClibc and all users of kconfig will greatly benefit from this.

> In headlines that is:
> - Make CONFIG_ prefix configurable at buildtime
>   Basically adding -DCONFIG_=BR2_ will do the trick
> 
> - Use mainmenu entry as headline in the frontends
> 
> - Drop "kernel" from all help texts
>   So there is no longer any "kernel" texts hardcoded
> 
> I guess a few other nits I forgot.
> 
> I hope this is merged in next merge window - but no promises.

Ok. I'll try to update our package/config stuff against the mainline
kernel regularly, so that we can take advantage from this work.

FWIW, we also have other patches to scripts/kconfig besides
s/kernel/Buildroot/ and the change of the prefix. We have some stuff to
support the fact that the .config file and all related generated files
must be in the output directory in the case of an out-of-tree build. I
haven't look at those changes in detail, they were implemented by Peter.

Regards,

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

[Buildroot] Stuff for the next release (2010.11)

[Lionel Landwerlin]

Hello,

I'm joining Thomas to write a little about the work I'm doing on
Buildroot and that could be part of the next release (2010.11).

I started to work on package generation about 1 month ago
(http://potipota.net/cgi-bin/cgit.cgi/buildroot/log/?h=package-generation). The idea behind this is to generate a per package "tarball" of what is getting installed in the staging/target directories. This way, we could easily :
        * uninstall packages, by removing all files listed in the
        tarballs
        * generate packages in ipk (or whatever) format to easily update
        our rootfs ;)
After having been able to tarball some of the packages, I realized that
it won't work without important modifications about how we deal with
libtooled packages and more particulary with libraries compiled with
libtool. Indeed, to be able to cross compiled library with libtool, we
currently use 2 tricks :
        * a libtool patch to fix some cross compilation problems with
        libtool
        * we edit all .la files to replace the path to the libraries
        (ie. /usr/lib by $(STAGING_DIR)/usr/lib)
This second point is the main problem I'm facing to generate correct
tarballs at the moment, and it also led me to investigate the problem we
have with libtool.

I started to rework the way we work with libtool about 2 weeks ago
(http://potipota.net/cgi-bin/cgit.cgi/buildroot/log/?h=new-libtool-at-work).
Here is at quick list of impacts :
        * it is now required to run autoreconf on all the libtooled
        packages
        * we can get rid of adding -L$(STAGING_DIR)/lib -L
        $(STAGING_DIR)/usr/lib to LDFLAGS
        * the libtool patch isn't used anymore
At the moment I'm having something that work, but in a limited
configuration (with glibc external toolchains). The sum of modified code
is quite small at the moment, but it has a significant impact on a lot
of packages (everything using libtool, which means probably most of the
libraries). I will give an update later on the list to detail the
remaining problems.

All this stuff is in ugly/not-complete state at the moment, but I hope
to complete the libtool stuff pretty soon.

Regards,

-- 
Lionel Landwerlin