Re: pkg/48961 (make update from lang/g95 breaks blas, lapack, numpy, etc.)

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

The following reply was made to PR pkg/48961; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost,
	dholland%eecs.harvard.edu@localhost
Subject: Re: pkg/48961 (make update from lang/g95 breaks blas, lapack, numpy,
 etc.)
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) || \
 >      !empty(PKGPATH:Mdevel/libtool-base)
 >  IGNORE_G95=	yes
 >  MAKEFLAGS+=	IGNORE_G95=yes
 >  .endif
 >  
 >  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.
 
 Joerg