Today we have "tc-is-cross-compiler" function from "toolchain-funcs.eclass", which is very useful for knowing if we can run the recently built binary to generate misc files (like bash completion for various rust/go packages). The current implementation is simple, but first I don't know if it covers every possibility, and maybe the PM can select it in a better way. But inheriting the complicated eclass just for this function is somewhat sad. So maybe introduce a new function, with simpler name "is_cross", "iscross", ... Another option is to just move it into a new eclass, which is more slim, but maybe PMS is actually a good place for this function.
Wait, we have a function for that? I always thought the condition is so simple that it makes sense to just inline it.
(In reply to Michał Górny from comment #1) > Wait, we have a function for that? I always thought the condition is so > simple that it makes sense to just inline it. I think a function is nicer, since people can mistake, not think on every edge case, and if we need to update it (cause we change crossdev), changing a single place is better than all places.
If it's an EAPI function, you can't change it.
(In reply to Michał Górny from comment #3) > If it's an EAPI function, you can't change it. If I understand it correct, the API must remain the same (function name, args, result same type), but the implementation can change by the PM to be as appropriate as needed?
I don't really care that the eclass has other stuff in it. Quite often, you do need to call tc-getCC or similar. I actually don't like the current definition of tc-is-cross-compiler, or at least a differently-named function should usually be used instead. The condition it should really check for is probably [[ -n ${SYSROOT} ]]. If you're building against a different SYSROOT, you shouldn't try to (directly) execute anything from it, even if it is for the same tuple. What we do need (and I should have filed a bug for already, sorry) is a USE flag for this condition, similar to the old EAPI 5-hdepend "targetroot" flag. For the same reason above, I didn't want to call it anything like "cross", but I haven't decided on a good name yet. The flag is primarily meant to be used in *DEPEND variables where a package can only be cross-compiled with itself, but it would also mean you effectively get a helper for free. > if use other-sysroot; then
FWIW, I'd suggest we hold off (but not a "veto") until Chewi and I can hash out any other "cross-related" changes.
(In reply to Arthur Zamarin from comment #4) > If I understand it correct, the API must remain the same (function name, > args, result same type), but the implementation can change by the PM to be > as appropriate as needed? Err, yes and no. For some functions (like user patches), the implementation may be pretty much left to the package manager. However, for functions where you expect ebuilds to behave consistently (read: not suddenly fail if one package manager implements something slightly differently), the PMS needs to explicitly define the behavior. I'm not 100% sure here but I think this case is closer to the latter than the former.
