On Wed, 22 Nov 2006 03:10:45 -0500 (EST) Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> There are packages (such as perl) which work fine on both x86 and arm, > but don't build on x86 cross-compiling for arm. Furthermore, pam-0.78 can > be cross-compiled (with a patch available in bug comments), but pam-0.99 > will require more work to get to cross-compile. It would be useful to be > able to have 0.99 use a keyword (or something) such that it is excluded > from cross-compiles and these builds get 0.78 instead. > > I've got a working patch that extends the KEYWORDS semantics slightly, > such that, if KEYWORDS includes -foo, and ACCEPT_KEYWORDS includes foo but > not -foo, the package is masked, even if KEYWORDS also includes bar and > ACCEPT_KEYWORDS also includes bar. > > Then you can have the ACCEPT_KEYWORDS value "$ARCH cross" and packages > with KEYWORDS including "-cross" will be masked, unless you have "-cross" > in packages.keywords. > > This probably horribly mangles the concept of KEYWORDS, but I can't really > tell from reading the documentation that it doesn't work this way. (Of > course, I know it doesn't from trying things and reading the source, > but...) It doesn't specify whether "foo" or "-bar" on a package takes > precedence if "foo" and "bar" both apply to the system. (Of course, it > does say that keywords are always ARCHes, which would imply that only one > could apply.) I think this all works as expected, however, except that a > package having "cross" means that it is known to automatically work if > you're cross-compiling, rather than simply meaning that it is known > to work if you're cross-compiling and it would work if you were building > natively on your target. No. -foo is reserved for incremental negation. Maybe that isn't widely used in ACCEPT_KEYWORDS, but it has valid uses there and there can't be repurposed. Is there a particular reason why you don't use the normal keyword logic (KEYWORDS=cross and setting -cross in p.keywords to mask a package), or simply a package.mask entry? Marius -- [email protected] mailing list
