On Wed, May 16, 2012 at 9:58 AM, Peter Seebach <[email protected]> wrote: > On Wed, 16 May 2012 07:35:45 +0300 > Saul Wold <[email protected]> wrote: > >> My understanding is that a _subtract is fraught with danger, there >> all sorts of ordering implications. > > Yes. > > But consider, if you will, the specific case of > DISTRO_FEATURES_LIBC_DEFAULT, and a libc which is just like eglibc > except that it lacks RPC. > > Anything I do that isn't processed at the tail end of everything, > around the point where _appends are processed, will be unable to > cleanly obtain "the value that would have been set by default if > nothing else happened", and then remove a word from it. I can't set a > value in advance, because if I do the ?= won't fire and none of those > words will get set. I can't necessarily set a value later. > > Overrides won't work either, because overrides also destroy the > existing values. > > It seems to me that for a subtraction to work, it *must* be the very > last thing done. > > Basically, the purpose of suggesting this as a formal behavior defined > to be The Very Last Thing is to minimize the complexity of the ordering > implications. You get exactly what you would have gotten otherwise, > with these words removed.
I agree. I think this is the only sane option for implementing this given bitbake's current behavior. Clearly a -= would be extremely problematic, and would have clear complications with variable expansion, as we discussed on IRC. I'd be interested in seeing a prototype implementation of this, to experiment with it and see how viable it is. -- Christopher Larson _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
