[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/48961 (make update from lang/g95 breaks blas, lapack, numpy, etc.)
The following reply was made to PR pkg/48961; it has been noted by GNATS.
From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost,
Subject: Re: pkg/48961 (make update from lang/g95 breaks blas, lapack, numpy,
Date: Fri, 23 Jan 2015 12:47:09 +0100
On Fri, Jan 23, 2015 at 12:05:00AM +0000, David Holland wrote:
> Now I do. The problem is this clause at the beginning of g95.mk:
> .if !empty(PKGPATH:Mlang/g95) || !empty(PKGPATH:Mdevel/patch) || \
> IGNORE_G95= yes
> MAKEFLAGS+= IGNORE_G95=yes
> make update passes MAKEFLAGS when building depending packages, so
> IGNORE_G95 gets passed along and messes up their builds.
> I suppose it needs to be in MAKEFLAGS when building depends to avoid
> potential cycles; but does anything G95 depends on use FORTRAN? My
> guess would be no and that it's therefore not needed...
Does this logic have any point? The libtool-base part should be
obsolete, devel/patch is normally not used and doesn't have a dependency
cycle either. So the question just remains if lang/g95 needs the special
handling -- it certainly doesn't need need to be recursive though.
Main Index |
Thread Index |