Ian Stakenvicius schrieb: > On 25/08/13 10:15 AM, Ulrich Mueller wrote: >>>>>>> On Sun, 25 Aug 2013, Thomas Sachau wrote: > >>> workaround: add a variable, which changes the return of the >>> function checking for the current ABI (always true with variable, >>> without only true, when $ABI == $DEFAULT_ABI) > >> Would this variable be set by the user, in profiles, or in >> ebuilds? > >>> first version (multilib1.patch) directly changes the output of >>> the currently used multilib_is_native_abi() function: > >> I think this would be very misleading. If a function is called >> multilib_is_native_abi then it should test for exactly that, not >> for something else. > > > - From the discussion on this that we had ~2 weeks ago, it seems that > 'multilib_is_native_abi' is only used in the wild now (and only meant > to be used) to handle the cases where we want to say, build everything > for default_abi and only build certain bits for the others. > > If there was a common usage that is important for the actual native > abi (for instance, some sort of check enabling alternate code in a > build system for a specific CHOST or whatnot), then keeping > multilib_is_native_abi as it is would make a lot of sense, but since > there isn't any cases of this I'm not sure it matters -- changing it's > functionality to essentially become multilib_is_default_abi() (whether > we rename it or not) seems to make the most sense to me.
While there may currently only be one usecase for the function, it may be used in other cases too with time and wider usage of the new multilib eclasses. If i modify the function for the binaries part, this would require a new function for other usecases. If this really does not happen, the multilib_is_native_abi function could still be deprecated and removed in the future. So i decided to go with a new function. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
