Re: BB_STAMP_POLICY

[Detlef Vollmann <dv@vollmann.ch>]

Koen Kooi wrote:
> 11:37:33 Koen: is BB_STAMP_POLICY documented somewhere?
> 11:37:47 Richard Purdie: Not really
> 11:38:03 Richard Purdie: Takes the values "file" "whitelist" or "full"
> 11:38:35 Richard Purdie: "file" is the traditional behaviour with stamps 
> just checked within a given recipe
> 11:38:46 Richard Purdie: "full" checks all the dependencies are consistent
> 11:39:12 Richard Purdie: "whitelist" allows some packages to be excluded 
> from the stamp checking basically so packages staging can work
Just for info: I've tested "whitelist" pretty extensivly over the past
few weeks and I'm pretty confident that all the bugs are fixed now.

But I've run into a fundamental problem with dependency checking:
for one of our projects we're changing frequently between NPTL
and linuxthreads for glibc (we'd like to use NPTL for the features,
but run again and again into problems with NPTL).
Normally, this change is just a flip of GLIBC_ADDONS in the distro
config file.  But of course the value of this specific variable
is not tracked by the dependency checking (which is IMHO correct).
So what I did is to split the glibc recipes into a linuxthreads
one and an NPTL one (which was quite some exercise).
Now I face the problem to separate glibc between "--with-tls"
and "--without-tls", which would be a change for
EXTRA_OECONF_glibc-linuxthreads in my distro conf file, but
again this defeats dependency tracking.  So I would have to
split glibc(-linuxthreads) again, but I'm a bit reluctant
to do so...

One solution for that would be to introduce something like
use flags, which could be included into the stamp information
and used for dependency checking.  But there were a number
of discussions about use flags on this list and there was
quite some opposition.
IIRC, this opposition was mainly against the cross-package
nature of use flags, but we don't need this for dependency
checking.  What we need is a naming scheme that the dependency
checker knows about so that it can include specific variables
into the stamp information, something like
USE_glibc_ADDONS = "nptl"
USE_glibc_EXTRA_OECONF = "--with-tls --with-__thread"

What do people think about this, or is there a completely
different way to solve the underlying problem?

   Detlef