"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes: > Agreed. My main point that influences the defaults is the header > directories also for netlib cblas and lapacke (with symlinks) and the > change to openblas packages to also include the C APIs. The main > consumer of that is numpy, which I of course will test into the freeze. If you can have built it before commit, and your chanages are expected not to have unforeseen consequences on systems you didn't test on, that sounds fine. > The option to use the 64 bit variants as dependencies might appear in > time, but it will not be the default until the next freeze at least. ok, sounds good > A design decision to discuss is the handling of blas/blas64 generic > dependencies. > > BLAS_C_INTERFACE=yes > BLAS_INDEX64=yes > .include ../../mk/blas.buildlink3.mk > > vs. either > > .include ../../mk/blas64.buildlink3.mk > > or > > .include ../../mk/blas.buildlink3.mk > > The separte files would be mutually exclusive anyway. I would tend to one file, as two gives the impression it's more different than it is and perhaps should be usable in parallel.
Attachment:
signature.asc
Description: PGP signature