math/blas linking to gfortran with LDADD?= -lgfortran

b. f. bf1783 at googlemail.com
Wed Sep 1 03:06:04 UTC 2010


On 8/31/10, jhell <jhell at dataix.net> wrote:
> Looking closer at the math/blas & math/lapack ports:
>
> This statement does not make any sense. The logic is backwards for every
> instance. And WITH_PROFILE would do.
> .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE))
> PLIST_FILES+=   lib/libblas_p.a
> .endif
>
> Which is basically saying:
> Add that profile lib if NOPROFILE is not defined "_p is a profiled lib
> why would you want to install this if the admin has NOT defined NOPROFILE?
>

Er, I'm not sure what you're getting at here. No means no.  Really.
The default, as I explained, is to build and install the profiling
libraries, unless one or more of three disabling variables has been
defined. And that's the default because users of these ports often use
the profiled libraries when analyzing performance of their programs,
which are usually computationally-intensive.  Why the three variables?
 Because they control whether the profiling libraries are actually
built via bsd.compat.mk and bsd.lib.mk.

>
> Simple following would do.
> .if (defined(WITH_PROFILE)
> PLIST_FILES+=   lib/libblas_p.a
> ,endif
>
> Then if it is really a concern that this has to default to on, then use
> the options framework to present that to the user. At least in this
> instance the user will at least know whats going on.

As I wrote earlier, there needs to be some additional logic here, at
least warnings about NO*, and maybe some other steps.  There is a
confluence of base system options with port options here.  I will
discuss it with the maintainer.

b.


More information about the freebsd-ports mailing list