tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: BLAS in pkgsrc: present and future



"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes:

> Am Thu, 30 May 2019 08:49:53 -0400
> schrieb Greg Troxel <gdt%lexort.com@localhost>: 
>
>> I wonder if it would be simpler to have a default value of
>> PKGSRC_BLAS_PREFERRED, if not set by the user.
>
> OK, so the mk file would use an internal _PKGSRC_BLAS_PREFERRED for
> that.

There are cases for things like choosing the postgres version that
already have the separation of user-settable, package-settable, and
internal variables.   I would suggest looking at that, and also the gcc
version selection logic.

>> > The package uses PKGSRC_BLAS_TYPE for the build.  
>> 
>> (same comment about a different variable)
>
> So, would it be the preferred way to use _PKGSRC_BLAS_TYPE in the
> package Makefiles? I don't care that much either way, but I want
> to make sure that this verbosity is consensus. I don't recall seeing
> that many _UNDERSCORE variable names in use.

I don't see that this would show up in the package makefile at all.  I
would expect that the package would set the ACCEPTED variable and then


.include ../../mk/blas.mk

or perhaps

.include ../../math/blas/blas.mk

(the latter if there is a  long-term stable standard approach, and I
would lean to mk/blas.mk)

which then

  - figures out which version should be used
  - includes the appropriate bl3 for it.

> Is it still fine to have BLAS_LIBS and LAPACK_LIBS defined? Should those
> be _PKGSRC_BLAS_LIBS, _BLAS_LIBS?

If those are defined by the bl3 file and expected to be used in
CONFIGURE_ARGS in depending packages, those variables sound appropriate.

I think if you look at the gcc, pgsql, kerberos and ncurses code (really
all mk/foo.mk for foo a kind of program name), this will be clearer.
(I realize most people never have to understand all those details.)


Home | Main Index | Thread Index | Old Index