Task-base is big :(

Task-base is big :(

[Marcin Juszkiewicz]

After long time of doing mostly Poky builds I did few Angstrom builds from 
OE.dev and found that amount of dependencies during build time has grown 
into very long list. It is 2388 tasks now just for "bitbake task-base" 
for fic-gta01 MACHINE.

How to reduce it? Few ideas from me:

1. Switch PACKAGES list to contain only stuff covered by MACHINE_FEATURES

This will give less stuff to build as there will be no building of not 
needed stuff (like pcmciautils for example). We use that way in Poky.

2. Create bluez-utils-lite which do not depend on gstreamer and cups

Those targets adds lot of extra dependencies for build time and many of OE 
users (NOTE: not OE derived distros) do not use that stuff anyway. But 
selecting does build as to use bluez-utils(-full) or lite need to be 
selectable by user also then only by distro.

Poky dropped cups dependency but keeps gstreamer ones but our users do 
full builds usually so gstreamer is built by default.

For MACHINE = "fic-gta01" DISTRO="angstrom-2007.1" I got:

- 1371 tasks for bluez-utils
- 1352 tasks for bluez-utils w/o cups
-  957 tasks for bluez-utils w/o gstreamer
-  868 tasks for bluez-utils w/o cups & gstreamer

503 tasks less is BIG change.

3. Merge gconf-dbus_svn.bb from Poky

In Poky we disabled GTK dependency (only gconf-sanity-check use it) so 
gstreamer/gst-plugins-base will not depend on gtk+. X11 will be built 
anyway.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

         A user friendly computer first requires a friendly user.

Re: Task-base is big :(

[Leon Woestenberg]

Hello all,

On 9/11/07, Marcin Juszkiewicz <openembedded@haerwu.biz> wrote:
>
> After long time of doing mostly Poky builds I did few Angstrom builds from
> OE.dev and found that amount of dependencies during build time has grown
> into very long list. It is 2388 tasks now just for "bitbake task-base"

Most of  your suggestion would end-up having a "USE" flags approach.

I also think the dependencies (whether run-time or build-time) grow
out of hand, and are very hard to get rid of building for true
embedded systems where the software is embedded as firmware and
nothing extra can be installed subsequently.

The TASK-* and *FEATURES approach looked good at first instance, but I
have reverted from using it, as it still results in a major cloud of
package (build) dependencies.

My current approach is maintaining an overlay with copied and adapted
options and dependencies but I would rather see this supported within
OpenEmbedded.

Maybe a minimal set of USE flags instead of creating -lite or -minimal
.bb is an option?
Or, using an include file that defines configuration variables
(HAVE_GTK, HAVE_X)?

Regards,
-- 
Leon

Re: Task-base is big :(

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> Hello all,
> 

> Maybe a minimal set of USE flags instead of creating -lite or -minimal
> .bb is an option?
> Or, using an include file that defines configuration variables
> (HAVE_GTK, HAVE_X)?

Any form of USE flags is *bad* and *unacceptable*. I'll leave it to the other core people
to throw around terms like 'deterministic' and 'package space' :)

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG5uwIMkyGM64RGpERAi0IAJ9PQlx4QvSPiTwJnu7uz6ZEk/y8/wCghoJF
fpxV38r3QzACxaFvG+Xwbrc=
=pK1Q
-----END PGP SIGNATURE-----

USE flags - why they won't work for OE

[Richard Purdie]

On Tue, 2007-09-11 at 21:27 +0200, Koen Kooi wrote:
> Leon Woestenberg schreef:
> > Hello all,
> > 
> 
> > Maybe a minimal set of USE flags instead of creating -lite or -minimal
> > .bb is an option?
> > Or, using an include file that defines configuration variables
> > (HAVE_GTK, HAVE_X)?
> 
> Any form of USE flags is *bad* and *unacceptable*. I'll leave it to the other core people
> to throw around terms like 'deterministic' and 'package space' :)

Agreed. I will try and keep this brief whilst putting something in the
archives once and for all.

If we implement USE flags people can no longer know what options
"matchbox-wm" (or whatever other package) was compiled with. Reproducing
builds then becomes a nightmare and differences would not be obvious. It
also has potential to break dependencies since something depending on
matchbox-wm might need certain configure options and it has no way to
specify this in the package dependencies. 

We'd also get people complaining that they enabled gtk, built a
gpe-image in an existing build directory and why did it screw up badly
with half the components compiled without gtk? USE flags would be
something totally outside the existing dependency and timestamp/rebuild
tracking which is already complex enough.

Given this, the agreed approach in the past has been to create things
like "bluez-utils-nodbus". Its obvious whats missing from that package
and it works in feeds and dependencies.

Marcin's proposal of "bluez-utils-lite" is therefore in keeping with
this idea and he's demonstrated a clear cut need for it (massively
reduced build time for small images).

I'd also point out that OE has managed extremely well up to this point
without USE flags. I agree there are some corner cases where they're
help in theory but we can solve these problems in other ways.

Suggestions for better ways to handle this are extremely welcome but
"USE flags" as I understand the idea would turn into a nightmare and any
proposal needs to work for OE, not shoehorn in something from elsewhere
which doesn't fit.

Cheers,

Richard

Re: USE flags - why they won't work for OE

[Leon Woestenberg]

Hello Richard,

On 9/11/07, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Tue, 2007-09-11 at 21:27 +0200, Koen Kooi wrote:
> > Leon Woestenberg schreef:
> > > Hello all,
> > >
> >
> > > Maybe a minimal set of USE flags instead of creating -lite or -minimal
> > > .bb is an option?
> > > Or, using an include file that defines configuration variables
> > > (HAVE_GTK, HAVE_X)?
> >
> > Any form of USE flags is *bad* and *unacceptable*. I'll leave it to the other core people
> > to throw around terms like 'deterministic' and 'package space' :)
>
> Agreed. I will try and keep this brief whilst putting something in the
> archives once and for all.
>
Clear. So we use the bitbake recipe namespace to create a diverse set
of packages.

Let's at least come up with a good way of using the namespace:

-lite has been suggested, which I do not prefer (ambiguous, and I
would prefer -light)
-nodbus (if dbus dependency is dropped)

I would prefer using:

-without-x
-without-gtk
-without-dbus
...

as the package suffix, as it re-uses the "configure" options
namespace, well known to most developers.

Also, -minimal comes to mind for a truely minimally configured package.

Regards,
-- 
Leon

Re: USE flags - why they won't work for OE

[Stelios Koroneos]

> Let's at least come up with a good way of using the namespace:
>
> -lite has been suggested, which I do not prefer (ambiguous, and I
> would prefer -light)
> -nodbus (if dbus dependency is dropped)
>
> I would prefer using:
>
> -without-x
> -without-gtk
> -without-dbus
> ...
>
> as the package suffix, as it re-uses the "configure" options
> namespace, well known to most developers.

Both comments are correct, but what happens in the case we have a package
with multiple -without-xyz ?


Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com

Re: USE flags - why they won't work for OE

[José Bernardo Bandos Rodrigues]

May I add some noise into this argument? A few years ago I contributed to a
source based linux distro. The way we had around this weren't USE flags - we
had as part of the package description files (what you have in .bb files) a
file that had prompts to be given to the user at package configure time, and
what dependencies changed and what arguments were passed to ./configure as a
result of those prompts. Since this was at package configure time, and that
step would run before everything else, the user would get a bunch of prompts
at the beginning, and the results would be stored for future use. The user
could also specify a option to the package build tool to discard these
stored results and re-ask the prompts. A file with the stored dependencies
would also be updated as a result of this, by the dependency checking code
of the package builder. That file would allow one to examine/reproduce a
particular user configuration, if needed.

2007/9/12, Stelios Koroneos <skoroneos@digital-opsis.com>:
>
> > Let's at least come up with a good way of using the namespace:
> >
> > -lite has been suggested, which I do not prefer (ambiguous, and I
> > would prefer -light)
> > -nodbus (if dbus dependency is dropped)
> >
> > I would prefer using:
> >
> > -without-x
> > -without-gtk
> > -without-dbus
> > ...
> >
> > as the package suffix, as it re-uses the "configure" options
> > namespace, well known to most developers.
>
> Both comments are correct, but what happens in the case we have a package
> with multiple -without-xyz ?
>
>
> Stelios S. Koroneos
>
> Digital OPSiS - Embedded Intelligence
> http://www.digital-opsis.com
>
>
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: USE flags - why they won't work for OE

[Darcy Watkins]

Hello,

My two bits worth (Canadian - now almost at par with US currency.  ;-)

In the buildroot project, they use:

  $ make menuconfig

... to configure the system to be built and to select packages.  Then it
is all built up using auto configure type tools.  In fact, they even
have targets at the buildroot Makefile level that allow running the
menuconfig target for uclibc and busybox.

Perhaps an OE distro could provide the default answers to a similar
scheme, but the user should be able to run the menu config to change the
choices.  It would also be cool if the "lite" and other options could be
default rule filters to apply to a distro to change the default choices
before invoking the menu config.

After this, the build process should still check for dependencies and
include those needed but which were not chosen.  This has the added
benefit that if you remake down the road after removing packages, any
dependencies no longer needed would no longer be included.

It would be nice to run something like:

  <utilname>  DISTRO=angstrom.2007.1 MACHINE=myppcbox \
    DEFAULTS=uclibc-lite,busybox-lite,packages-lite,secure-web-lite

...etc.  The filters could be run in some agreed order (e.g. left to
right) so it will be well understood how conflicts between filter files
will be resolved.

It would generate some .bb files to be included.  Then away to the
races...

An alternative would be to list the filters in the local config file and
just have bitbake invoke the menuconfig program when it detects a change
made to the list of filters.  For those who hate having the build
process launch an interactive application, have an
abort-on-config-change provision with output instructing the user to
manually run a menuconfig program.

I understand that there is value to consumer handheld devices to have a
package manager to run on the target to install and upgrade
applications, but that isn't of much use to smaller embedded appliances
where it is more important that the vendor strictly control the software
configurations that their support team will handle.  In such cases,
software upgradeability is typically managed more at the level of
filesystem images than as individual files and it is rare that the end
user is able to change anything other than user settings and preferences
stored in some form of a database.


Regards,

Darcy

Re: USE flags - why they won't work for OE

[Leon Woestenberg]

Hello all,

On 9/12/07, Stelios Koroneos <skoroneos@digital-opsis.com> wrote:
> > Let's at least come up with a good way of using the namespace:
> >
> > -lite has been suggested, which I do not prefer (ambiguous, and I
> > would prefer -light)
> > -nodbus (if dbus dependency is dropped)
> >
> > I would prefer using:
> >
> > -without-x
> > -without-gtk
> > -without-dbus
> > ...
> >
> > as the package suffix, as it re-uses the "configure" options
> > namespace, well known to most developers.
>
> Both comments are correct, but what happens in the case we have a package
> with multiple -without-xyz ?
>
That's exactly why I think the configuration namespace should not be
performed in the package naming.

Although it might work for only a limited number of configuration
items (no X, not GTK, no sound, ...) it quickly becomes hairy.

However, we could start this way, and tidy later.

It seems to be the way of least resistance at this point.

I will commit whatever I think is useful to others. I am sure at some
point someone will stand up and disagree with me then :-)

Regards,

Leon.

Re: USE flags - why they won't work for OE

[Richard Purdie]

On Wed, 2007-09-12 at 13:46 +0200, Leon Woestenberg wrote:
> On 9/12/07, Stelios Koroneos <skoroneos@digital-opsis.com> wrote:
> That's exactly why I think the configuration namespace should not be
> performed in the package naming.
> 
> Although it might work for only a limited number of configuration
> items (no X, not GTK, no sound, ...) it quickly becomes hairy.
> 
> However, we could start this way, and tidy later.
> 
> It seems to be the way of least resistance at this point.
> 
> I will commit whatever I think is useful to others. I am sure at some
> point someone will stand up and disagree with me then :-)

Please don't start adding every possible variant of configure options as
things will quickly get insane. I think this is only going to be needed
in a handful of places as in most cases its possible to use a common set
of options. If I'm wrong about that we need to rethink.

On that note if anyone wants to start adding secondary (or more)
versions of a package in this manner please discuss it on this list
first.

Thanks,

Richard

Re: Task-base is big :(

[Richard Purdie]

I've covered USE flags in a different mail so I'm ignoring that in this
reply.

On Tue, 2007-09-11 at 19:37 +0200, Leon Woestenberg wrote:
> The TASK-* and *FEATURES approach looked good at first instance, but I
> have reverted from using it, as it still results in a major cloud of
> package (build) dependencies.

This is the same issue Marcin wants to address.

> My current approach is maintaining an overlay with copied and adapted
> options and dependencies but I would rather see this supported within
> OpenEmbedded.

Is this overlay public? Even if we can't use it directly a summary of
what you find unacceptable of the current approach in OE would be useful
to see. Personally, I don't think there are that many dependency issues
but I'd be interested to see how much of OE you needed to patch. Perhaps
you could write a quick summary?

We're never going to manage something that works for everyone perfectly
out the box but I think things can certainly be improved from where they
are now.

Also keep in mind the task-base I checked in was very much a first
draft, it has evolved since and I'm fully expecting it to evolve again
in the future! :)

Cheers,

Richard

Re: Task-base is big :(

[Detlef Vollmann]

Richard Purdie wrote:
> Is this overlay public? Even if we can't use it directly a summary of
> what you find unacceptable of the current approach in OE would be useful
> to see.
I don't have a full overlay, but here's an example:
$ cat python-my_2.5.1.bb
require python_${PV}.bb

DEPENDS = "python-native readline zlib gdbm openssl sqlite3 tcl"

EXTRA_OECONF = "--with-threads --with-pymalloc --with-cyclic-gc \
                --with-signal-module --with-wctype-functions \
                --enable-shared"

PROVIDES += "python"

The difference to the original python .bb is the removing of
 DEPEND: tk
  This would build a whole X11 system, and I definitely don't want that.

 EXTRA_OECONF: --without-cxx
  I want the C++, so I configure it with it.

The interesting part cannot be seen here: the package is lying.
python_2.5.1.bb is including python-2.5-manifest.inc, and that
declares to provide "python-tkinter" which is simply wrong.
But to remove that would either mean to provide a full own
edited copy of the manifest, or to remove the wrong declarations
again, which requires syntax I don't know.

 Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/

Re: Task-base is big :(

[Leon Woestenberg]

Hello,

On 9/12/07, Detlef Vollmann <dv@vollmann.ch> wrote:
> Richard Purdie wrote:
> > Is this overlay public? Even if we can't use it directly a summary of
> > what you find unacceptable of the current approach in OE would be useful
> > to see.
> I don't have a full overlay, but here's an example:
> $ cat python-my_2.5.1.bb

> The difference to the original python .bb is the removing of
>  DEPEND: tk
>   This would build a whole X11 system, and I definitely don't want that.
>

Same here, but I guess we are using OE for similar purposes. Using
OpenEmbedded for embedded applications you build a kernel, need a
*few* packages (say 10) and some custom stuff (say 20 packages).

Removing stuff like X or XML dependencies from the bitbake of those
handful of packages allows me to build reasonably quick and especially
the build does not break when any of the redundant packages breaks.

I plan to bring a OE monotone and package mirror and the overlay
online soon. I also have spare hours on a build server that could be
used to build public targets, I would like to dedicate this to
regression testing.

Regards,
-- 
Leon

Re: Task-base is big :(

[Stelios Koroneos]

> > The difference to the original python .bb is the removing of
> >  DEPEND: tk
> >   This would build a whole X11 system, and I definitely don't want that.
> >
>
> Same here, but I guess we are using OE for similar purposes. Using
> OpenEmbedded for embedded applications you build a kernel, need a
> *few* packages (say 10) and some custom stuff (say 20 packages).
>

True.
As more people start to use OE and as these people would be mostly
interested in "vertical" solutions (develop an app or add apps to an
existing distro without having to rebuild everything) i think we need to
have a closer look at the OE SDK vs build everything from scratch.
Having a "standard" toolchain availiable (and the way to use it) for people
that are not interested in developing distro's would IMHO provide additional
"user friendliness" and make OE an even more attractive solution.

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces@openembedded.org
> [mailto:openembedded-devel-bounces@openembedded.org]On Behalf Of
> Leon Woestenberg
> Sent: Wednesday, September 12, 2007 1:55 AM
> To: openembedded-devel@openembedded.org
> Subject: Re: [oe] Task-base is big :(
>
>
> Hello,
>
> On 9/12/07, Detlef Vollmann <dv@vollmann.ch> wrote:
> > Richard Purdie wrote:
> > > Is this overlay public? Even if we can't use it directly a summary of
> > > what you find unacceptable of the current approach in OE
> would be useful
> > > to see.
> > I don't have a full overlay, but here's an example:
> > $ cat python-my_2.5.1.bb
>
> Removing stuff like X or XML dependencies from the bitbake of those
> handful of packages allows me to build reasonably quick and especially
> the build does not break when any of the redundant packages breaks.
>
> I plan to bring a OE monotone and package mirror and the overlay
> online soon. I also have spare hours on a build server that could be
> used to build public targets, I would like to dedicate this to
> regression testing.
>
> Regards,
> --
> Leon
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Task-base is big :(

[Graeme Gregory]

Stelios Koroneos wrote:
> True.
> As more people start to use OE and as these people would be mostly
> interested in "vertical" solutions (develop an app or add apps to an
> existing distro without having to rebuild everything) i think we need to
> have a closer look at the OE SDK vs build everything from scratch.
> Having a "standard" toolchain availiable (and the way to use it) for people
> that are not interested in developing distro's would IMHO provide additional
> "user friendliness" and make OE an even more attractive solution.
>   
I personally think this discussion is a clear example of why Koen's
work on packaged staging needs to be finished.

Just think how much faster you could build if all the system did was
download and install these dependencies rather than build them
from scratch.

Graeme

Re: Task-base is big :(

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graeme Gregory schreef:
> Stelios Koroneos wrote:
>> True.
>> As more people start to use OE and as these people would be mostly
>> interested in "vertical" solutions (develop an app or add apps to an
>> existing distro without having to rebuild everything) i think we need to
>> have a closer look at the OE SDK vs build everything from scratch.
>> Having a "standard" toolchain availiable (and the way to use it) for people
>> that are not interested in developing distro's would IMHO provide additional
>> "user friendliness" and make OE an even more attractive solution.
>>   
> I personally think this discussion is a clear example of why Koen's
> work on packaged staging needs to be finished.

There's a proof of concept patch at http://bugs.openembedded.org/show_bug.cgi?id=2948,
which needs at least a cleanup to make it possible to use .debs.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG56aaMkyGM64RGpERAnWnAJwO1+ZDriFctPSwHCJC+Oh6GMBCcQCfd1DZ
BSDeSMHVTjCr5h+8OSl9Z7g=
=JRez
-----END PGP SIGNATURE-----

Binary packages (was: Task-base is big :( )

[Detlef Vollmann]

This thread touches two very interesting, but not directly
related issues, so I decided to split here.

Graeme Gregory wrote:
> I personally think this discussion is a clear example of why Koen's
> work on packaged staging needs to be finished.
> 
> Just think how much faster you could build if all the system did was
> download and install these dependencies rather than build them
> from scratch.
Exactly.

For our current project, we have a build system based on
Gentoo's portage, and we're currently planning to switch to
OpenEmbedded.
We want to be able to build everything ourselves from scratch,
and we do that.  But we don't want to do that each time we
build an (internal) release (we do sometimes several releases
a week and a full build including toolchain takes about
two hours).
So in our current build system, we just use portage's --usepkg,
and if the package we want to build is already built and in
our repository, we just unpack that (unfortunately this doesn't
always work as expected, but that's a different story).
For OpenEmbedded, I looked at options how I could do something
similar, and I came up with some ideas.

First, we need to care for everything a recipe does.
For the staging part I hoped that packaged staging solves the
problem (and from the discussion in
http://bugs.openembedded.org/show_bug.cgi?id=354
I thought it might already work, but I didn't test it yet).
But there are other things (like ipkg-make-index) and I don't
know what to do about those.  Possibly just not allowing
binary packages for such recipes.

Then we have the problem that most recipes build more than one ipk,
so we have to put all of them into one combined file, probably
an ipk package that just contains other ipk packages.

So I thought about two possible solutions to get binary packages:
 one - to add an option like '--usepkg' to bitbake and let bitbake
       take care of everything.
 two - putting the required actions into the recipes themselves
       (possibly by using some bbclasses).
       http://bugs.openembedded.org/show_bug.cgi?id=2948
       seems to implement this approach at least partly, but
       I don't understand that fully yet and I still have to
       test it to get a better feeling for it.

 Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/

Re: Task-base is big :(

[Detlef Vollmann]

Stelios Koroneos wrote:
> > Same here, but I guess we are using OE for similar purposes. Using
> > OpenEmbedded for embedded applications you build a kernel, need a
> > *few* packages (say 10) and some custom stuff (say 20 packages).
This is one usage we have, for specific projects.

> As more people start to use OE and as these people would be mostly
> interested in "vertical" solutions (develop an app or add apps to an
> existing distro without having to rebuild everything) i think we need to
> have a closer look at the OE SDK vs build everything from scratch.
Actually, for projects that are in a stage where they start to
build (internal) releases (that go to some test procedures),
building from scratch is important to be able to reproduce
these releases and apply some minor bugfixes to them.
But that doesn't mean that everything should be built from
scratch for each release (see me other mail on binary packages).
For packages used in these project I have no problems to put
in some effort to provide the packages in my overlay and tweak
some until they contain exactly what I need.

But we have always a number of project that just start to develop
or are still exploring their development options.
For those projects I try to provide "mini-distros" based
on existing distros (angstrom).  For these mini-distros
I prepare a feed that contains everything that builds and makes
sense for their hardware (so I mask everything related to
graphics and multimedia).

My current approach is to start with a big list of packages
setup a BBMASK and see what builds.  Those that don't build
I simply remove from my list or (if I think the package is
interesing enough) I try to modify that package in my
overlay so that it builds.

For such packages (for which I don't know whether they are ever
really used in any project) I'm a bit reluctant to put in much
effort, so I'd appreciate everything that makes my job here
easier.

> Having a "standard" toolchain availiable (and the way to use it) for people
> that are not interested in developing distro's would IMHO provide additional
> "user friendliness" and make OE an even more attractive solution.
Definitely.  But even for people like me (who provide some
infrastructure to a number of projcets inside a company or for
a given hardware) it would be nice to make "distro building"
easier.

  Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/

Re: Task-base is big :(

[Richard Purdie]

On Wed, 2007-09-12 at 08:56 +0300, Stelios Koroneos wrote:
> As more people start to use OE and as these people would be mostly
> interested in "vertical" solutions (develop an app or add apps to an
> existing distro without having to rebuild everything) i think we need to
> have a closer look at the OE SDK vs build everything from scratch.
> Having a "standard" toolchain availiable (and the way to use it) for people
> that are not interested in developing distro's would IMHO provide additional
> "user friendliness" and make OE an even more attractive solution.

Poky has some partially developed ideas here. Have a look at:

http://pokylinux.org/autobuild/toolchain/2732/poky-0.0-snapshot-20070912-arm-toolchain.tar.bz2
and
http://pokylinux.org/autobuild/toolchain/2732/poky-0.0-snapshot-20070912-i586-toolchain.tar.bz2

These are two toolchains that can be used in two ways:

1. As an external SDK style standalone toolchain
2. When combined with a poky build it becomes a poor mans "packaged
staging" which removes the toolchain build time from the equation by
using this prebuilt toolchain + glibc package.

OE has half the needed functionality since meta-toolchain works the same
in OE as it does in Poky now and will generate tarballs like the above.

The missing link is a distro configuration to actually use such a
generated tarball in OE.

Whilst Poky doesn't package much in the way of libraries, they would be
straight forward to add just by adding the package names to the
appropriate tasks.

Cheers,

Richard 

Re: Task-base is big :(

[Dr. Michael Lauer]

Detlef Vollmann wrote:
> The difference to the original python .bb is the removing of
>  DEPEND: tk
>   This would build a whole X11 system, and I definitely don't want that.

Hmm, I'm sure it's just an example for you, but anyway I can't leave
it unsaid: Python's dependency on Tk just drags in libx11 and libxext
at build time -- I don't see this as being a problem, since they don't
end up the image unless you want to.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Task-base is big :(

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dr. Michael Lauer schreef:
> Detlef Vollmann wrote:
>> The difference to the original python .bb is the removing of
>>  DEPEND: tk
>>   This would build a whole X11 system, and I definitely don't want that.
> 
> Hmm, I'm sure it's just an example for you, but anyway I can't leave
> it unsaid: Python's dependency on Tk just drags in libx11 and libxext
> at build time -- I don't see this as being a problem, since they don't
> end up the image unless you want to.

And bluez-utils is exactly the same.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG54GAMkyGM64RGpERAi1mAJ9eG0E/w1KGqc3YKJBQ+ih+xluXqwCeMCEX
tnPbiKP6qWYC102Y2tzwyvk=
=BOmp
-----END PGP SIGNATURE-----

Splitting up bluez in a sane way, was Re: Task-base is big :(

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Dr. Michael Lauer schreef:
>> Detlef Vollmann wrote:
>>> The difference to the original python .bb is the removing of
>>>  DEPEND: tk
>>>   This would build a whole X11 system, and I definitely don't want that.
>> Hmm, I'm sure it's just an example for you, but anyway I can't leave
>> it unsaid: Python's dependency on Tk just drags in libx11 and libxext
>> at build time -- I don't see this as being a problem, since they don't
>> end up the image unless you want to.
> 
> And bluez-utils is exactly the same.

What can be done is to make the default bluez-utils build only build bluez-utils* and have
seperate recipes for all the 3rdparty stuff it builds:

FILES_${PN}-alsa = "${libdir}/alsa-lib/libasound*"
FILES_bluez-cups-backend = "${libdir}/cups/backend/bluetooth"

That would solve both buildtime and runtime issues.

What do you think?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG6jaFMkyGM64RGpERApT1AKCd2c3/aLUbt2Tq6nf8Dy1GCTl8aACfWqE7
M4/wIIN/uJky4n1rqdGS7C0=
=o+aN
-----END PGP SIGNATURE-----

Re: Splitting up bluez in a sane way, was Re: Task-base is big :(

[Marcin Juszkiewicz]

Dnia piątek, 14 września 2007, Koen Kooi napisał:

> What can be done is to make the default bluez-utils build only build
> bluez-utils* and have seperate recipes for all the 3rdparty stuff it
> builds:

> That would solve both buildtime and runtime issues.
>
> What do you think?

bluez-utils-cups, bluez-utils-gstreamer, bluez-utils-alsa? Sounds good for 
me - especially first both.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

          bloody internet
          there was once peace and then the internet came in :-)

Re: Splitting up bluez in a sane way, was Re: Task-base is big :(

[Koen Kooi]

Marcin Juszkiewicz schreef:
> Dnia piątek, 14 września 2007, Koen Kooi napisał:
> 
>> What can be done is to make the default bluez-utils build only build
>> bluez-utils* and have seperate recipes for all the 3rdparty stuff it
>> builds:
> 
>> That would solve both buildtime and runtime issues.
>>
>> What do you think?
> 
> bluez-utils-cups, bluez-utils-gstreamer, bluez-utils-alsa? Sounds good for 
> me - especially first both.


bluez-utils-cups and bluez-utils-alsa can be done for sure, but I haven't looked at where
gstreamer comes in and if it can be a seperate package.

regards,

Koen

Re: Splitting up bluez in a sane way, was Re: Task-base is big :(

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 9249 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Marcin Juszkiewicz schreef:
>> Dnia piątek, 14 września 2007, Koen Kooi napisał:
>>
>>> What can be done is to make the default bluez-utils build only build
>>> bluez-utils* and have seperate recipes for all the 3rdparty stuff it
>>> builds:
>>> That would solve both buildtime and runtime issues.
>>>
>>> What do you think?
>> bluez-utils-cups, bluez-utils-gstreamer, bluez-utils-alsa? Sounds good for 
>> me - especially first both.
> 
> 
> bluez-utils-cups and bluez-utils-alsa can be done for sure, but I haven't looked at where
> gstreamer comes in and if it can be a seperate package.

What do you think of this patch?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG65f+MkyGM64RGpERAjykAKC6h9p8EPGj2e1bLRZVyVUWM3d/ZQCePdiE
K2akk6htq346s6KfG250gYs=
=dAPx
-----END PGP SIGNATURE-----
#
# old_revision [ed2dc1d95bc34057f0b86292d7754ebbccb01504]
#
# add_file "packages/bluez/bluez-cups-backend_3.18.bb"
#  content [6d3dd18f0576378f8bae0c3e251bce0ca132176e]
# 
# add_file "packages/bluez/bluez-libs_3.18.bb"
#  content [dc7c9ab3cf4931c0678271b1a5ef7511ebb7b82d]
# 
# add_file "packages/bluez/bluez-utils-alsa_3.18.bb"
#  content [b7eb82c734b71cf61ac35a052d87da836df665d4]
# 
# add_file "packages/bluez/bluez-utils3.inc"
#  content [67f1049d4efcca0d1468bbd4b8a4773c40c05d2f]
# 
# add_file "packages/bluez/bluez-utils_3.18.bb"
#  content [6eab1b4ae54ca017408988788320c718efedc784]
#
============================================================
--- packages/bluez/bluez-cups-backend_3.18.bb	6d3dd18f0576378f8bae0c3e251bce0ca132176e
+++ packages/bluez/bluez-cups-backend_3.18.bb	6d3dd18f0576378f8bae0c3e251bce0ca132176e
@@ -0,0 +1,26 @@
+require bluez-utils3.inc
+
+DEPENDS += "cups"
+
+# see bluez-utils3.inc for the explanation of these option
+EXTRA_OECONF = " \
+                 --enable-bccmd \
+		 --enable-hid2hci \
+                 --disable-alsa \ 
+		 --enable-cups \
+		 --enable-glib \
+		 --disable-sdpd \
+	         --enable-network \
+	         --enable-serial \
+	         --enable-input \
+	         --enable-audio \
+	         --enable-echo \
+                 --enable-configfile \
+	         --enable-initscripts \
+		 --enable-test \
+		" 
+
+PACKAGES = "${PN}"
+
+FILES_${PN} = "${libdir}/cups/backend/bluetooth"
+RDEPENDS_${PN} = "cups"
============================================================
--- packages/bluez/bluez-libs_3.18.bb	dc7c9ab3cf4931c0678271b1a5ef7511ebb7b82d
+++ packages/bluez/bluez-libs_3.18.bb	dc7c9ab3cf4931c0678271b1a5ef7511ebb7b82d
@@ -0,0 +1 @@
+require bluez-libs.inc
============================================================
--- packages/bluez/bluez-utils-alsa_3.18.bb	b7eb82c734b71cf61ac35a052d87da836df665d4
+++ packages/bluez/bluez-utils-alsa_3.18.bb	b7eb82c734b71cf61ac35a052d87da836df665d4
@@ -0,0 +1,24 @@
+require bluez-utils3.inc
+
+DEPENDS += "alsa-lib"
+
+# see bluez-utils3.inc for the explanation of these option
+EXTRA_OECONF = " \
+                 --enable-bccmd \
+		 --disable-hid2hci \
+                 --enable-alsa \ 
+		 --disable-cups \
+		 --enable-glib \
+		 --disable-sdpd \
+	         --enable-network \
+	         --enable-serial \
+	         --enable-input \
+	         --enable-audio \
+	         --enable-echo \
+                 --enable-configfile \
+	         --enable-initscripts \
+		 --enable-test \
+		" 
+
+PACKAGES = "${PN}"
+FILES_${PN} = "${libdir}/alsa-lib/libasound*"
============================================================
--- packages/bluez/bluez-utils3.inc	67f1049d4efcca0d1468bbd4b8a4773c40c05d2f
+++ packages/bluez/bluez-utils3.inc	67f1049d4efcca0d1468bbd4b8a4773c40c05d2f
@@ -0,0 +1,143 @@
+DESCRIPTION = "Linux Bluetooth Stack Userland Utilities."
+SECTION = "console"
+PRIORITY = "optional"
+DEPENDS = "gstreamer gst-plugins-base bluez-libs-${PV} libusb dbus glib-2.0"
+PROVIDES = "bluez-utils-dbus"
+RPROVIDES_${PN} = "bluez-pan bluez-sdp bluez-utils-dbus"
+RREPLACES = "bluez-utils-dbus"
+RCONFLICTS_${PN} = "bluez-utils-nodbus"
+LICENSE = "GPL"
+
+# ti patch doesn't apply, people using it should rediff it and send it upstream
+SRC_URI = "http://bluez.sourceforge.net/download/bluez-utils-${PV}.tar.gz \
+           file://hcid.conf \
+#           file://hciattach-ti-bts.patch;patch=1 \
+
+S = "${WORKDIR}/bluez-utils-${PV}"
+
+inherit autotools update-rc.d
+
+EXTRA_OECONF = " \
+                 --enable-bccmd \
+		 --enable-hid2hci \
+                 --enable-alsa \ 
+		 --enable-cups \
+		 --enable-glib \
+		 --disable-sdpd \
+	         --enable-network \
+	         --enable-serial \
+	         --enable-input \
+	         --enable-audio \
+	         --enable-echo \
+                 --enable-configfile \
+	         --enable-initscripts \
+		 --enable-test \
+		" 
+
+# The config options are explained below:
+
+#  --enable-obex           enable OBEX support
+#  --enable-alsa           enable ALSA support, not needed for nokia770, nokia800 and fic-gtao1
+#  --enable-cups           install CUPS backend support
+#  --enable-bccmd          install BCCMD interface utility
+#  --enable-avctrl         install Audio/Video control utility
+#  --enable-hid2hci        install HID mode switching utility
+#  --enable-dfutool        install DFU firmware upgrade utility
+
+#  --enable-glib           For systems that use and install GLib anyway
+#  --disable-sdpd          The sdpd is obsolete and should no longer be used. This of course requires that hcid will be started with -s to enable the SDP server
+
+#Following services can be enabled so far:
+#	--enable-network
+#	--enable-serial
+#	--enable-input
+#	--enable-audio
+#	--enable-echo
+
+#There is no need to modify any init script. They will be started
+#automatically or on demand. Only /etc/bluetooth/*.service files should
+#be patched to change name or the autostart value.
+#	--enable-configfile
+#	--enable-initscripts
+
+#For even smaller -doc packages
+#	--disable-manpages
+#	--disable-pcmciarules
+
+#I haven't seen any embedded device with HID proxy support. So simply
+#disable it:
+#	--disable-hid2hci
+
+
+do_install_append() {
+	install -d ${D}${base_sbindir} ${D}${base_bindir}/  ${D}${sysconfdir}/apm/event.d/
+	mv ${D}${sbindir}/* ${D}${base_sbindir}/
+	mv ${D}${bindir}/* ${D}${base_bindir}/
+	rmdir ${D}${bindir} ${D}${sbindir}
+	chmod u+s ${D}${base_sbindir}/hciattach ${D}${base_sbindir}/hciconfig
+	install -m 0644 ${WORKDIR}/hcid.conf ${D}${sysconfdir}/bluetooth/
+        install -m 0755 ${S}/daemon/.libs/passkey-agent ${D}${base_bindir}/
+}
+
+
+INITSCRIPT_NAME = "bluetooth"
+INITSCRIPT_PARAMS = "defaults 23 19"
+
+
+PACKAGES =+ "${PN}-compat"
+
+CONFFILES_${PN} = " \
+                   ${sysconfdir}/bluetooth/hcid.conf \
+                   ${sysconfdir}/default/bluetooth \
+                  "
+
+CONFFILES_${PN}-compat = " \
+                          ${sysconfdir}/bluetooth/rfcomm.conf \
+			 " 
+
+FILES_${PN} = " \
+               ${base_sbindir}/hcid \
+               ${libdir}/bluetooth \
+               ${sysconfdir}/init.d/bluetooth \
+               ${sysconfdir}/bluetooth/*.service \
+               ${sysconfdir}/bluetooth/hcid.conf \
+               ${sysconfdir}/default \
+               ${sysconfdir}/dbus-1 \
+	       ${base_sbindir}/hciattach \
+              "
+
+FILES_${PN}-dbg += " \
+                   ${libdir}/bluetooth/.debug \
+		   ${libdir}/cups/backend/.debug \
+		   ${libdir}/alsa-lib/.debug \
+		  " 
+
+FILES_${PN}-compat = " \
+                    ${base_bindir}/sdptool \
+                    ${base_bindir}/dund \
+		    ${base_bindir}/rctest \
+		    ${base_bindir}/ciptool \
+		    ${base_bindir}/l2test \
+		    ${base_bindir}/rfcomm \
+		    ${base_bindir}/hcitool \
+		    ${base_bindir}/pand \
+		    ${base_bindir}/hidd \
+		    ${base_bindir}/l2ping \
+		    ${base_sbindir}/hciconfig \
+                    ${base_sbindir}/bccmd \
+		    ${base_sbindir}/hciemu \
+		    ${base_sbindir}/hid2hci \
+		    ${base_bindir}/passkey-agent \
+		    ${sysconfdir}/bluetooth/rfcomm.conf \
+		   " 
+
+
+
+
+
+
+
+
+
+
+
============================================================
--- packages/bluez/bluez-utils_3.18.bb	6eab1b4ae54ca017408988788320c718efedc784
+++ packages/bluez/bluez-utils_3.18.bb	6eab1b4ae54ca017408988788320c718efedc784
@@ -0,0 +1,23 @@
+require bluez-utils3.inc
+
+# see bluez-utils3.inc for the explanation of these option
+EXTRA_OECONF = " \
+                 --enable-bccmd \
+		 --enable-hid2hci \
+                 --disable-alsa \ 
+		 --disable-cups \
+		 --enable-glib \
+		 --disable-sdpd \
+	         --enable-network \
+	         --enable-serial \
+	         --enable-input \
+	         --enable-audio \
+	         --enable-echo \
+                 --enable-configfile \
+	         --enable-initscripts \
+		 --enable-test \
+		" 
+
+
+CONFFILES_${PN} = "${sysconfdir}/bluetooth/hcid.conf ${sysconfdir}/bluetooth/rfcomm.conf \
+	${sysconfdir}/default/bluetooth"

Re: Splitting up bluez in a sane way, was Re: Task-base is big :(

[Marcin Juszkiewicz]

Dnia sobota, 15 września 2007, Koen Kooi napisał:
> Koen Kooi schreef:
> > Marcin Juszkiewicz schreef:
> >> Dnia piątek, 14 września 2007, Koen Kooi napisał:
> >>> What can be done is to make the default bluez-utils build only
> >>> build bluez-utils* and have seperate recipes for all the 3rdparty
> >>> stuff it builds:
> >>> That would solve both buildtime and runtime issues.
> >>>
> >>> What do you think?
> >>
> >> bluez-utils-cups, bluez-utils-gstreamer, bluez-utils-alsa? Sounds
> >> good for me - especially first both.
> >
> > bluez-utils-cups and bluez-utils-alsa can be done for sure, but I
> > haven't looked at where gstreamer comes in and if it can be a
> > seperate package.
>
> What do you think of this patch?

Looks ok - in cups you can disable hid2hci and in both probably few other 
options can be disabled but their compile time is small rather so better 
leave as they are.

Did you tried to create separate gst-plugin-bluez recipe?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

 Learn the facts and make up your own damn mind. That's why you have one.

Re: Splitting up bluez in a sane way, was Re: Task-base is big :(

[Koen Kooi]

Marcin Juszkiewicz schreef:
> Dnia sobota, 15 września 2007, Koen Kooi napisał:
>> Koen Kooi schreef:
>>> Marcin Juszkiewicz schreef:
>>>> Dnia piątek, 14 września 2007, Koen Kooi napisał:
>>>>> What can be done is to make the default bluez-utils build only
>>>>> build bluez-utils* and have seperate recipes for all the 3rdparty
>>>>> stuff it builds:
>>>>> That would solve both buildtime and runtime issues.
>>>>>
>>>>> What do you think?
>>>> bluez-utils-cups, bluez-utils-gstreamer, bluez-utils-alsa? Sounds
>>>> good for me - especially first both.
>>> bluez-utils-cups and bluez-utils-alsa can be done for sure, but I
>>> haven't looked at where gstreamer comes in and if it can be a
>>> seperate package.
>> What do you think of this patch?
> 
> Looks ok - in cups you can disable hid2hci and in both probably few other 
> options can be disabled but their compile time is small rather so better 
> leave as they are.
> 
> Did you tried to create separate gst-plugin-bluez recipe?

Not yet, I wanted the easy stuff (bluez, alsa) to get seperated first.

regards,

Koen

Re: Splitting up bluez in a sane way, was Re: Task-base is big :(

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Marcin Juszkiewicz schreef:
>> Dnia sobota, 15 września 2007, Koen Kooi napisał:
>>> Koen Kooi schreef:
>>>> Marcin Juszkiewicz schreef:
>>>>> Dnia piątek, 14 września 2007, Koen Kooi napisał:
>>>>>> What can be done is to make the default bluez-utils build only
>>>>>> build bluez-utils* and have seperate recipes for all the 3rdparty
>>>>>> stuff it builds:
>>>>>> That would solve both buildtime and runtime issues.
>>>>>>
>>>>>> What do you think?
>>>>> bluez-utils-cups, bluez-utils-gstreamer, bluez-utils-alsa? Sounds
>>>>> good for me - especially first both.
>>>> bluez-utils-cups and bluez-utils-alsa can be done for sure, but I
>>>> haven't looked at where gstreamer comes in and if it can be a
>>>> seperate package.
>>> What do you think of this patch?
>> Looks ok - in cups you can disable hid2hci and in both probably few other 
>> options can be disabled but their compile time is small rather so better 
>> leave as they are.
>>
>> Did you tried to create separate gst-plugin-bluez recipe?
> 
> Not yet, I wanted the easy stuff (bluez, alsa) to get seperated first.

Committed, please report (or better fix :) ) any problems with it.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG8BDaMkyGM64RGpERAgFCAJsGSwSH59nQFio5HIgEfCz9yGzvLACgh65H
cuZPF+12wtemuBh+4J4pxZg=
=j9DI
-----END PGP SIGNATURE-----