1 |
Hi, |
2 |
|
3 |
This discussion emerged from https://github.com/gentoo/sci/pull/876. I |
4 |
am taking it here for better future reference. |
5 |
|
6 |
cdluminate: |
7 |
> It would be problematic to provide int64 ABI/API through libblas.so or |
8 |
> liblapack.so since that would lead to a mess with the int32 |
9 |
> ABI/API. Adding the int64 USE flags to existing packages will make it |
10 |
> hard to write ebuilds for users who want e.g. both int32 and int64 |
11 |
> openblas at the same time. My personal recommendation is to provide a |
12 |
> new set of packages, say eselect-{blas64,lapack64} + sci-libs/lapack64, |
13 |
> which are clearly isolated with the int32 ones. These new packages |
14 |
> should change SONAMEs into say libblas64.so and liblapack64.so. This is |
15 |
> the same as what I'm doing for Debian's 64bit-indexing BLAS/LAPACK |
16 |
> packages. |
17 |
|
18 |
heroxbd: |
19 |
> We can make int64 as a use flag and by enabling it we install 2 sets of |
20 |
> libraries: libblas.so and libblas64.so. What do you think? |
21 |
|
22 |
kiwifb: |
23 |
> I know why you want that @heroxbd - you want to avoid ebuild |
24 |
> duplication. On the face of it it is less ebuilds to maintain in |
25 |
> exchange of more complex ebuilds. However I think it would still be |
26 |
> wise to have at least separate virtuals - that means dependencies on |
27 |
> int32 and int64 are completely separate and allow a different set of |
28 |
> implementations without impinging on each other. |
29 |
|
30 |
> Whether to go for doubling the ebuilds or making them more complex is |
31 |
> up to the maintainer. And we have to deal with the headers in any |
32 |
> case. |
33 |
|
34 |
cdluminate: |
35 |
> I agree with @kiwifb . At least we need |
36 |
> virtual/{blas64,cblas64,lapack64,lapacke64}. For the implementations |
37 |
> we could introduce two new USE flags: int32 and int64, where each of |
38 |
> them could trigger a separate full build, and int32 is enabled by |
39 |
> default. Same for the eselect packages. |
40 |
|
41 |
I agree with int32 and int64 USE flags. but int32 and int64 is too |
42 |
simple and misleading, how about index_int32 and index_int64? They are |
43 |
named after python_targets_python3_7. |
44 |
|
45 |
Virtual/blas could do the same: virtual/blas[index_int32,index_int64]. |
46 |
|
47 |
Yours, |
48 |
Benda |