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:
>> I don't think there's much chance of collisions using BLAS_*, but it is
>> theoretically possible that an application could use something like
>> BLAS_PREFERRED with different semantics. Using PKGSRC_BLAS_* might be
>> better just for the sake of self-documentation, so people know at a
>> glance that they're looking at a PKGSRC knob rather than an upstream knob.
>
> Are we talking about the variables to be set in mk.conf now or also
> about the resulting variables blas.bl3.mk sets for the package?
> Everything shall have PKGSRC_ prefix? Also BLAS_LIBS?
>
> What would an upstream knob look like in a pkgsrc Makefile? I mean …
> all variables there are pkgsrc variables, the upstream stuff is only
> explicitly set via MAKE_ENV etc. What's a possible case of confusion? I
> do see a possible conflict with the pkgsrc Makefile defining variables
> for local use, sure. But what's upstream here?
>
> I can deal with anything, just want to make sure what's the preferred
> way and I understand why.
My feeling, which you shouldn't take as particularly special, is that
new pkgsrc variables might as well start with PKGSRC_, so that it's
really obvious they are pkgsrc variables. And that there's no
particular reason to avoid doing so.
I think Jason is talking about some package's source tarball, for a
package that uses blas, and that can use multiple blas versions, and has
code to choose. Basically doing in the distfile what we are adding to
pkgsrc.
Home |
Main Index |
Thread Index |
Old Index