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