Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Andreas Oberritter <obi@opendreambox.org>]

On 11/19/2010 11:28 PM, Philip Balister wrote:
> I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With
> this commit my build that includes angstrom-task-gnome.bb fails in a
> peculiar way. Basically, my process table is filled with a task. Looks
> like it is trying to run a pkg-config gtk+ operation. This is with
> angstrom-2010.x and a custom machine very similar to an overo.
> 
> I realize this is a vague description, but I do not have time to isolate
> better at this time.
> 
> Can we go ahead and revert this for now?

No, please don't.

I'm 100% sure that this patch is the only sane way of handling
pkg-config files. I hope you agree that it wasn't possible for me to
test every single package before this got merged.

Still, the solution for problems popping up now is simple: Make sure
that required libraries install their pkg-config files themselves.
Usually, they would already do it, but their install rules are
overridden by custom do_install or do_stage rules in their bitbake recipe.

As you already mentioned, the package causing the problem is gtk+
(gtk+-1.2_1.2.10.bb).

The solution in this case is very likely to
- remove do_stage
- add ${bindir}/gtk-config to FILES_${PN}-dev
- bump PR

The real problem is gtk-config going crazy when gtk's pkg-config file is
not installed.

I'd have already submitted a patch, but testing takes a lot of time,
especially when a recipe takes down the build machine.

Maybe it would be wise for bitbake or OE to set ulimit -u to a sane
value. Is there a way for a process to count the number of its direct
and indirect child processes?

Regards,
Andreas