| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 25/08/13 10:15 AM, Ulrich Mueller wrote: |
| 5 |
>>>>>> On Sun, 25 Aug 2013, Thomas Sachau wrote: |
| 6 |
> |
| 7 |
>> workaround: add a variable, which changes the return of the |
| 8 |
>> function checking for the current ABI (always true with variable, |
| 9 |
>> without only true, when $ABI == $DEFAULT_ABI) |
| 10 |
> |
| 11 |
> Would this variable be set by the user, in profiles, or in |
| 12 |
> ebuilds? |
| 13 |
> |
| 14 |
>> first version (multilib1.patch) directly changes the output of |
| 15 |
>> the currently used multilib_is_native_abi() function: |
| 16 |
> |
| 17 |
> I think this would be very misleading. If a function is called |
| 18 |
> multilib_is_native_abi then it should test for exactly that, not |
| 19 |
> for something else. |
| 20 |
> |
| 21 |
|
| 22 |
- From the discussion on this that we had ~2 weeks ago, it seems that |
| 23 |
'multilib_is_native_abi' is only used in the wild now (and only meant |
| 24 |
to be used) to handle the cases where we want to say, build everything |
| 25 |
for default_abi and only build certain bits for the others. |
| 26 |
|
| 27 |
If there was a common usage that is important for the actual native |
| 28 |
abi (for instance, some sort of check enabling alternate code in a |
| 29 |
build system for a specific CHOST or whatnot), then keeping |
| 30 |
multilib_is_native_abi as it is would make a lot of sense, but since |
| 31 |
there isn't any cases of this I'm not sure it matters -- changing it's |
| 32 |
functionality to essentially become multilib_is_default_abi() (whether |
| 33 |
we rename it or not) seems to make the most sense to me. |
| 34 |
|
| 35 |
|
| 36 |
>> second version (multilib2.patch) creates a new function, which |
| 37 |
>> should then be used by ebuild authors to check, if they should |
| 38 |
>> build ABI-specific content or not (using build_binaries() |
| 39 |
>> function instead of multilib_is_native_abi() function) |
| 40 |
> |
| 41 |
> +build_binaries() { |
| 42 |
> |
| 43 |
> Name space pollution? Prefix with "multilib" please. |
| 44 |
> |
| 45 |
> + if [[ ${COMPLETE_MULTILIB} == yes ]] ; then + return 0 + else + |
| 46 |
> multilib_is_native_abi + fi |
| 47 |
> |
| 48 |
> This can be expressed much shorter (and clearer): |
| 49 |
> |
| 50 |
> [[ ${COMPLETE_MULTILIB} == yes ]] || multilib_is_native_abi |
| 51 |
> |
| 52 |
> But allow me a stupid question, why do you want to build binaries |
| 53 |
> for other ABIs anyway? It's called multilib, not multibin. |
| 54 |
> |
| 55 |
> Ulrich |
| 56 |
> |
| 57 |
|
| 58 |
Some users want to have a toolchain that is 64bit and the rest of the |
| 59 |
userspace that is 32bit. Or, they want to just have certain packages |
| 60 |
installed 32bits, to support specific use-cases. Essentially, the |
| 61 |
want to have multi-abi instead of multi-lib, and so they want the |
| 62 |
current multi-lib to be expanded to allow them to do it. |
| 63 |
|
| 64 |
|
| 65 |
-----BEGIN PGP SIGNATURE----- |
| 66 |
Version: GnuPG v2.0.20 (GNU/Linux) |
| 67 |
|
| 68 |
iF4EAREIAAYFAlIbYR8ACgkQ2ugaI38ACPBG8AEAgcED8DZxyN0c98nMKvkCwNRG |
| 69 |
zO6AcwF83oBL0PzOErsA/0gPMFZsX0+sKOXHo557L9X0Ha3S+9V8ZQVDWBVVL0Xk |
| 70 |
=pvlE |
| 71 |
-----END PGP SIGNATURE----- |
Archives