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