NetBSD Problem Report #21932

Received: (qmail 12960 invoked by uid 605); 19 Jun 2003 17:56:10 -0000
Message-Id: <200306191756.h5JHu3f20427@digital.clock.org>
Date: Thu, 19 Jun 2003 10:56:03 -0700 (PDT)
From: fair@netbsd.org
Sender: gnats-bugs-owner@netbsd.org
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: pkgsrc should support CPUFLAGS from /etc/mk.conf
X-Send-Pr-Version: 3.95

>Number:         21932
>Category:       pkg
>Synopsis:       pkgsrc should support CPUFLAGS from /etc/mk.conf
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 19 17:57:02 +0000 2003
>Closed-Date:    
>Last-Modified:  Mon May 23 02:50:01 +0000 2022
>Originator:     Erik E. Fair
>Release:        NetBSD-current
>Organization:
The NetBSD Project
>Environment:
>Description:
	NetBSD sets its compilers to deliver maximum binary compatability
	across the series of platforms that share a CPU, e.g. all NetBSD/alpha
	systems have compilers that will compile to the 21064, the first alpha.
	This is great for an initial install, and for installations that have
	a wide range of a given family of systems which share binaries on NFS.
	This practice also means we can support the widest range of systems
	with one binary release per platform.

	However, this practice also means that NetBSD does not take advantage
	of performance enhancing improvements in the instruction sets of later
	models of the Alpha, e.g. the 21164a, which has the BWX instructions.
	In short, on single systems, we often do not perform as well as we
	could. GCC 3.3 promises to make this disparity worse, by providing
	more complete support for instruction sheduling, and CPU-specific
	instruction generation.

	In order to make it easier to compile CPU-specific binaries, Jason
	Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
	distinct from CFLAGS, so that they can be easily included without
	stomping on other things that are added to CFLAGS (e.g. optimization
	flags).

	I think that pkgsrc should support this also, to the extent that it
	is possible to do within the confines of third-party supplied "make"
	procedures which may or may not actually involve BSD make(1); it is
	especially important that those third party applications which we
	support perform as well as they can on the user's chosen platform when
	the user chooses to optimize for that platform.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:

From: David Brownlee <abs@netbsd.org>
To: fair@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Fri, 20 Jun 2003 17:14:01 +0100 (BST)

 On Thu, 19 Jun 2003 fair@netbsd.org wrote:

 > 	In order to make it easier to compile CPU-specific binaries, Jason
 > 	Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
 > 	distinct from CFLAGS, so that they can be easily included without
 > 	stomping on other things that are added to CFLAGS (e.g. optimization
 > 	flags).

 	I was under the impression that COPTS could be used for this
 	purpose in the base system.

 	devel/cpuflags installs a cpuflags.mk file that sets CPU_FLAGS
 	then:

 .ifdef BSD_PKG_MK                       # Try to catch various package opts
 CFLAGS+=${CPU_FLAGS}
 CXXFLAGS+=${CPU_FLAGS}
 MAKE_FLAGS+=CCOPTIONS="${CPU_FLAGS}"    # Override CCOPTIONS for imake

 .else                                   # Assume in base system, only COPTS
 COPTS?=${CPU_FLAGS} ${DEFCOPTS}
 # Include ${DEFCOPTS} and set ?= to allow overriding in kernel builds

 .endif

 	I would suggest adding something like the following to bsd.pkg.mk:

 .if defined(PKG_CPUFLAGS)
 CFLAGS+=${PKG_CPUFLAGS}
 CXXFLAGS+=${PKG_CPUFLAGS}
 MAKE_FLAGS+=CCOPTIONS="${PKG_CPUFLAGS}"    # Override CCOPTIONS for imake
 .endif

 	That would allow people to set PKG_CPUFLAGS and CPUFLAGS
 	differently.

 -- 
 		David/absolute          -- www.netbsd.org: No hype required --

From: fredb@immanent.net (Frederick Bruckman)
To: fair@netbsd.org, abs@netbsd.org, fredb@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Mon, 23 Jun 2003 12:43:19 -0500 (CDT)

 In article <200306191756.h5JHu3f20427@digital.clock.org>,
 	fair@netbsd.org writes:
 > 
 > 	In order to make it easier to compile CPU-specific binaries, Jason
 > 	Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
 > 	distinct from CFLAGS, so that they can be easily included without
 > 	stomping on other things that are added to CFLAGS (e.g. optimization
 > 	flags).
 > 
 > 	I think that pkgsrc should support this also, to the extent that it
 > 	is possible to do within the confines of third-party supplied "make"
 > 	procedures which may or may not actually involve BSD make(1)...

 I agree completely. I'd even thought of doing something similiar to that.

 From: David Brownlee <abs@netbsd.org>
 To: fair@netbsd.org
 Cc: gnats-bugs@gnats.netbsd.org
 Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
 Date: Fri, 20 Jun 2003 17:14:01 +0100 (BST)

 ....

         I would suggest adding something like the following to bsd.pkg.mk:

  .if defined(PKG_CPUFLAGS)
  CFLAGS+=${PKG_CPUFLAGS}
  CXXFLAGS+=${PKG_CPUFLAGS}
  MAKE_FLAGS+=CCOPTIONS="${PKG_CPUFLAGS}"    # Override CCOPTIONS for imake
  .endif

         That would allow people to set PKG_CPUFLAGS and CPUFLAGS
         differently.

 You can't... CPUFLAGS is automatically added to CFLAGS in <sys.mk> (for users
 of NetBSD 1.6U and newer), so every package that respects CFLAGS should get
 it already. Users can do the switch the ordinary way, with ".ifdef BSD_PKG_MK".
 Given that, the place to add it for the other folks is in "bsd.prefs.mk".

 More interesting, to me, is to find a way to distinguish the packages built
 with submodel flags that would make them unusable on other hosts. I feel that
 without this, a mixed collection will become unmanagable. My idea is to
 install the package with the same name as before, but only munge the name of
 the package tarball, by adding the contents of the "-march=" flag after the
 version number. The "-march" tag, I think is adequate for this -- builders
 of private collections can use that as a signal for less commonly used ABI
 breakers, if desired.

 The beauty of it, is, the dependency system in pkgsrc is ignorant of the
 name of the original tarball, so it's not affected, and the point of putting
 the tag after the version number, rather than before, is so that the wildcard
 dependencies will mostly take care of matching the slightly changed name by
 "pkg_add". (A few packages which don't use wildcards for dependencies would
 need fixing.)

 The following patch accomplishes this goal. Please test. The "pkg_add" part
 only mostly works: You can leave the suffix off of the invocation of "pkg_add"
 for the package you're installing directly, but for the dependencies in the
 package to be found in $PKG_PATH, "pkg_add" says it can't find them, but then
 installs them anyway. I guess "pkg_add" would need some fixing, too, perhaps,
 even, to respect a preference for packages with certain $CPUFLAGS values?


 Index: bsd.pkg.mk
 ===================================================================
 RCS file: /cvsroot/pkgsrc/mk/bsd.pkg.mk,v
 retrieving revision 1.1202
 diff -u -r1.1202 bsd.pkg.mk
 --- bsd.pkg.mk	2003/06/23 14:26:32	1.1202
 +++ bsd.pkg.mk	2003/06/23 16:45:01
 @@ -1069,7 +1069,7 @@

  PKGREPOSITORYSUBDIR?=	All
  PKGREPOSITORY?=		${PACKAGES}/${PKGREPOSITORYSUBDIR}
 -PKGFILE?=		${PKGREPOSITORY}/${PKGNAME}${PKG_SUFX}
 +PKGFILE?=		${PKGREPOSITORY}/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}

  CONFIGURE_DIRS?=	${WRKSRC}
  CONFIGURE_SCRIPT?=	./configure
 @@ -2246,15 +2246,15 @@
  				exit 1;					\
  			fi;						\
  		fi;							\
 -		${RM} -f ${PACKAGES}/$$cat/${PKGNAME}${PKG_SUFX};	\
 -		${LN} -s ../${PKGREPOSITORYSUBDIR}/${PKGNAME}${PKG_SUFX} ${PACKAGES}/$$cat; \
 +		${RM} -f ${PACKAGES}/$$cat/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}; \
 +		${LN} -s ../${PKGREPOSITORYSUBDIR}/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ${PACKAGES}/$$cat; \
  	done;
  .endif

  .if !target(delete-package-links)
  delete-package-links:
  	${_PKG_SILENT}${_PKG_DEBUG}\
 -	${FIND} ${PACKAGES} -type l -name ${PKGNAME}${PKG_SUFX} | ${XARGS} ${RM} -f
 +	${FIND} ${PACKAGES} -type l -name ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} | ${XARGS} ${RM} -f
  .endif

  .if !target(delete-package)
 @@ -3116,7 +3116,7 @@
  # Create a binary package from an install package using "pkg_tarup"
  tarup:
  	${_PKG_SILENT}${_PKG_DEBUG}					\
 -	${RM} -f ${PACKAGES}/All/${PKGNAME}${PKG_SUFX};			\
 +	${RM} -f ${PACKAGES}/All/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}; \
  	${SETENV} PKG_DBDIR=${PKG_DBDIR} PKG_SUFX=${PKG_SUFX}		\
  		PKGREPOSITORY=${PACKAGES}/All				\
  		${LOCALBASE}/bin/pkg_tarup ${PKGNAME};			\
 @@ -3124,7 +3124,7 @@
  		${MKDIR} ${PACKAGES}/$$CATEGORY;			\
  		cd ${PACKAGES}/$$CATEGORY;				\
  		${RM} -f ${PKGNAME}${PKG_SUFX};				\
 -		${LN} -s ../All/${PKGNAME}${PKG_SUFX};			\
 +		${LN} -s ../All/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX};	\
  	done

  # shared code for replace and undo-replace
 @@ -3172,7 +3172,7 @@
  	${ECHO_MSG} "*** WARNING - experimental target - data loss may be experienced ***"; \
  	oldpkgname=${PKGNAME};						\
  	newpkgname=`${CAT} ${WRKDIR}/.replace`;				\
 -	replace_action="${SETENV} ${PKG_ADD} ${WRKDIR}/$$newpkgname${PKG_SUFX}"; \
 +	replace_action="${SETENV} ${PKG_ADD} ${WRKDIR}/$$newpkgname${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}"; \
  	${_REPLACE};							\
  	${RM} ${WRKDIR}/.replace

 @@ -3552,8 +3552,8 @@
  		arch=${MACHINE_ARCH}; 					\
  		for site in ${BINPKG_SITES} ; do 			\
  			${ECHO} Trying `eval ${ECHO} $$site`/All ; 	\
 -			${SHCOMMENT} ${ECHO} ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${PKG_SUFX} ; \
 -			if ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${PKG_SUFX} ; then \
 +			${SHCOMMENT} ${ECHO} ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ; \
 +			if ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ; then \
  				${ECHO} "${PKGNAME} successfully installed."; \
  				break ; 				\
  			fi ; 						\
 @@ -4200,7 +4200,7 @@
  	if [ ! -d ${PKG_DBDIR}/${PKGNAME} ]; then			\
  		${ECHO_MSG} "${_PKGSRC_IN}> Registering installation for ${PKGNAME}"; \
  		${MKDIR} ${PKG_DBDIR}/${PKGNAME};			\
 -		${PKG_CREATE} ${PKG_ARGS_INSTALL} -O ${PKGFILE} > ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \
 +		${PKG_CREATE} ${PKG_ARGS_INSTALL} -O ${PKGNAME}${PKG_SUFX} > ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \
  		${CP} ${DESCR} ${PKG_DBDIR}/${PKGNAME}/+DESC;		\
  		${ECHO} ${COMMENT:Q} > ${PKG_DBDIR}/${PKGNAME}/+COMMENT; \
  		${CP} ${BUILD_VERSION_FILE} ${PKG_DBDIR}/${PKGNAME}/+BUILD_VERSION; \
 @@ -4380,7 +4380,8 @@
  #	the contents of ${PLIST_SRC}.
  #
  GENERATE_PLIST?=	${TRUE};
 -_GENERATE_PLIST=	${CAT} ${PLIST_SRC}; ${GENERATE_PLIST}
 +_GENERATE_PLIST=	${ECHO} "@name " ${PKGNAME};			\
 +			${CAT} ${PLIST_SRC}; ${GENERATE_PLIST}

  plist: ${PLIST}
  ${PLIST}: ${PLIST_SRC}
 Index: bsd.prefs.mk
 ===================================================================
 RCS file: /cvsroot/pkgsrc/mk/bsd.prefs.mk,v
 retrieving revision 1.113
 diff -u -r1.113 bsd.prefs.mk
 --- bsd.prefs.mk	2003/06/05 00:23:29	1.113
 +++ bsd.prefs.mk	2003/06/23 16:45:02
 @@ -259,6 +259,11 @@
  WHOLE_ARCHIVE_FLAG?=	${_OPSYS_WHOLE_ARCHIVE_FLAG}
  NO_WHOLE_ARCHIVE_FLAG?=	${_OPSYS_NO_WHOLE_ARCHIVE_FLAG}

 +# CPUFLAGS is automatically added to CFLAGS since about NetBSD 1.6U.
 +.if ${OPSYS} != "NetBSD" || (!empty(OS_VERSION:M1.5*) || !empty(OS_VERSION:M1.6[_.A-T]*))
 +CFLAGS+=		${CPUFLAGS}
 +.endif
 +
  .ifndef DIGEST
  DIGEST:=		${LOCALBASE}/bin/digest
  MAKEFLAGS+=		DIGEST=${DIGEST}


 Frederick

From: David Brownlee <abs@netbsd.org>
To: Frederick Bruckman <fredb@immanent.net>
Cc: fair@netbsd.org, fredb@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Tue, 24 Jun 2003 11:17:35 +0100 (BST)

 On Mon, 23 Jun 2003, Frederick Bruckman wrote:

 > More interesting, to me, is to find a way to distinguish the packages built
 > with submodel flags that would make them unusable on other hosts. I feel that
 > without this, a mixed collection will become unmanagable. My idea is to
 > install the package with the same name as before, but only munge the name of
 > the package tarball, by adding the contents of the "-march=" flag after the
 > version number. The "-march" tag, I think is adequate for this -- builders
 > of private collections can use that as a signal for less commonly used ABI
 > breakers, if desired.
 >
 > The beauty of it, is, the dependency system in pkgsrc is ignorant of the
 > name of the original tarball, so it's not affected, and the point of putting
 > the tag after the version number, rather than before, is so that the wildcard
 > dependencies will mostly take care of matching the slightly changed name by
 > "pkg_add". (A few packages which don't use wildcards for dependencies would
 > need fixing.)
 >
 > The following patch accomplishes this goal. Please test. The "pkg_add" part
 > only mostly works: You can leave the suffix off of the invocation of "pkg_add"
 > for the package you're installing directly, but for the dependencies in the
 > package to be found in $PKG_PATH, "pkg_add" says it can't find them, but then
 > installs them anyway. I guess "pkg_add" would need some fixing, too, perhaps,
 > even, to respect a preference for packages with certain $CPUFLAGS values?

 	I tend to have the following in mk.conf

 .ifdef LINTPKGSRC
 PACKAGES=${PKGSRCDIR}/packages
 .else
 PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
 .endif

 	${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
 	with spaces stripped, which can end up with things like
 	'-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'

 	We already have a situation where by default building binary
 	packages from two different architectures will result in
 	a mismatched collection of packages in pkgsrc/packages. Could
 	I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
 	have PACKAGES as above?

 -- 
 		David/absolute          -- www.netbsd.org: No hype required --

From: Frederick Bruckman <fredb@immanent.net>
To: David Brownlee <abs@netbsd.org>
Cc: fair@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Tue, 24 Jun 2003 10:33:58 -0500 (CDT)

 On Tue, 24 Jun 2003, David Brownlee wrote:

 > On Mon, 23 Jun 2003, Frederick Bruckman wrote:
 >
 > > More interesting, to me, is to find a way to distinguish the packages built
 > > with submodel flags that would make them unusable on other hosts.

 > 	I tend to have the following in mk.conf
 >
 > .ifdef LINTPKGSRC
 > PACKAGES=${PKGSRCDIR}/packages
 > .else
 > PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
 > .endif

 Hmm. I think it was a mistake in the first place, not to have
 ${MACHINE_ARCH} embedded in the filename of the binary package, so I
 wanted to see if it was possible to make that different from the
 package name. I see that it is. Maybe we should just go all the way
 with the idea, and put <machine-arch>-<submodel> in each package name?

 > 	${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
 > 	with spaces stripped, which can end up with things like
 > 	'-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'
 >
 > 	We already have a situation where by default building binary
 > 	packages from two different architectures will result in
 > 	a mismatched collection of packages in pkgsrc/packages. Could
 > 	I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
 > 	have PACKAGES as above?

 We have to be careful not to go too far. My favorite, this
 week is, "-O2 -march=k6-2 -ffast-math -finline-functions
 -maccumulate-outgoing-args -momit-leaf-frame-pointer".[*] The
 only part of that that actually matters, compatibility-wise, is the
 "-march=k6-2". Also keep in mind, that the user doesn't have to have
 cpuflags installed to set such options, and we really don't want to
 take chances that incompatible packages get mixed together on
 ftp.netbsd.org. Therefore, I feel we should calculate the tag
 in bsd.prefs.mk. Maybe something like this...?

 CPU_TAG=	${CPUFLAGS:M-march=*:S/march=//}
 CPU_TAG+=	${CPUFLAGS:M-m680*:S/-m//}
 CPU_TAG+=	${CPUFLAGS:M-msoft-float=*:S/-m//}

 ...and then, of course, that gets inserted in all the places I've
 already identified in the patch.

 Frederick


 [*] "-O3" turns on "-funroll-loops" and "-frename-registers", besides
 "-finline-functions". The documention points out that "-funroll-loops"
 isn't alway faster -- nor would you expect it to be -- and that
 "-frename-registers" is most useful on a architecture with lots of
 registers --- which i386 isn't. "-fomit-frame-pointer" doesn't even
 compile all of the time -- but "-momit-leaf-frame-pointer" hasn't
 given me any trouble, yet. "-maccumulate-outgoing-args" is
 speculative; it certainly does make the binary 5 - 10% bigger than
 without it (but not necessarily bigger than -funroll-loops), but I
 haven't done any benchmarks, yet.

From: David Brownlee <abs@netbsd.org>
To: Frederick Bruckman <fredb@immanent.net>
Cc: fair@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Thu, 26 Jun 2003 11:47:28 +0100 (BST)

 On Tue, 24 Jun 2003, Frederick Bruckman wrote:

 > On Tue, 24 Jun 2003, David Brownlee wrote:
 >
 > > On Mon, 23 Jun 2003, Frederick Bruckman wrote:
 > >
 > > > More interesting, to me, is to find a way to distinguish the packages built
 > > > with submodel flags that would make them unusable on other hosts.
 >
 > > 	I tend to have the following in mk.conf
 > >
 > > .ifdef LINTPKGSRC
 > > PACKAGES=${PKGSRCDIR}/packages
 > > .else
 > > PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
 > > .endif
 >
 > Hmm. I think it was a mistake in the first place, not to have
 > ${MACHINE_ARCH} embedded in the filename of the binary package, so I
 > wanted to see if it was possible to make that different from the
 > package name. I see that it is. Maybe we should just go all the way
 > with the idea, and put <machine-arch>-<submodel> in each package name?

 	I would prefer to see at least machine_arch details in the
 	default PACKAGES directory, to somewhat match the binary
 	packages on ftp.netbsd.org, but that is not a strong
 	preference over embedding the details in the filename.
 	Either would be _much_ better than where we are now.

 	We should take this up on tech-pkg@ or packages@.

 > > 	${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
 > > 	with spaces stripped, which can end up with things like
 > > 	'-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'
 > >
 > > 	We already have a situation where by default building binary
 > > 	packages from two different architectures will result in
 > > 	a mismatched collection of packages in pkgsrc/packages. Could
 > > 	I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
 > > 	have PACKAGES as above?
 >
 > We have to be careful not to go too far. My favorite, this
 > week is, "-O2 -march=k6-2 -ffast-math -finline-functions
 > -maccumulate-outgoing-args -momit-leaf-frame-pointer".[*] The
 > only part of that that actually matters, compatibility-wise, is the
 > "-march=k6-2". Also keep in mind, that the user doesn't have to have
 > cpuflags installed to set such options, and we really don't want to
 > take chances that incompatible packages get mixed together on
 > ftp.netbsd.org. Therefore, I feel we should calculate the tag
 > in bsd.prefs.mk. Maybe something like this...?
 >
 > CPU_TAG=	${CPUFLAGS:M-march=*:S/march=//}
 > CPU_TAG+=	${CPUFLAGS:M-m680*:S/-m//}
 > CPU_TAG+=	${CPUFLAGS:M-msoft-float=*:S/-m//}
 >
 > ...and then, of course, that gets inserted in all the places I've
 > already identified in the patch.

 	Hum... don't forget at least -mcpu and -mipsX. I'm actually
 	inclined to put all the non default flags in the tag, so you
 	have an accurate record of what was used to compile the
 	package.

 -- 
 		David/absolute          -- www.netbsd.org: No hype required --
From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org, David Brownlee <abs@netbsd.org>
Cc: 
Subject: Re: pkg/21932
Date: Sat, 4 Jul 2015 18:00:31 +0200

 David, are you still interested in something like this?

From: David Brownlee <abs@netbsd.org>
To: Benny Siegert <bsiegert@gmail.com>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@netbsd.org>
Subject: Re: pkg/21932
Date: Fri, 17 Jul 2015 11:07:28 +0100

 ...maybe. I confess I'm not doing much with cpuflags recently...

 On 4 July 2015 at 17:00, Benny Siegert <bsiegert@gmail.com> wrote:
 > David, are you still interested in something like this?

From: Benny Siegert <bsiegert@gmail.com>
To: David Brownlee <abs@netbsd.org>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@netbsd.org>
Subject: Re: pkg/21932
Date: Sat, 25 Jul 2015 16:34:57 +0200

 On Fri, Jul 17, 2015 at 12:07 PM, David Brownlee <abs@netbsd.org> wrote:
 > ...maybe. I confess I'm not doing much with cpuflags recently...

 Should I close it then, and you can reopen it in case?

From: David Brownlee <abs@netbsd.org>
To: Benny Siegert <bsiegert@gmail.com>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@netbsd.org>
Subject: Re: pkg/21932
Date: Mon, 27 Jul 2015 12:57:29 +0100

 I think that would be best - thanks

 On 25 July 2015 at 15:34, Benny Siegert <bsiegert@gmail.com> wrote:
 > On Fri, Jul 17, 2015 at 12:07 PM, David Brownlee <abs@netbsd.org> wrote:
 >> ...maybe. I confess I'm not doing much with cpuflags recently...
 >
 > Should I close it then, and you can reopen it in case?

From: "Erik E. Fair" <fair@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org,
    pkgsrc-bugs@netbsd.org
Subject: Re: pkg/21932
Date: Mon, 27 Jul 2015 12:14:51 -0700

 Please do not close this problem report - it is not resolved.

 	Erik <fair@netbsd.org>

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/21932
Date: Tue, 28 Jul 2015 08:14:33 +0000

 On Mon, Jul 27, 2015 at 07:15:00PM +0000, Erik E. Fair wrote:
  >  Please do not close this problem report - it is not resolved.

 Yes, that. Closing PRs just because they're old does not help anybody
 or anything...

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/21932
Date: Mon, 23 May 2022 02:45:09 +0000

 Seven years ago, I wrote:
  >  On Mon, Jul 27, 2015 at 07:15:00PM +0000, Erik E. Fair wrote:
  >   >  Please do not close this problem report - it is not resolved.
  >  
  >  Yes, that. Closing PRs just because they're old does not help anybody
  >  or anything...

 That said, this PR is now old enough to vote, and reviewing it, it's
 not entirely clear what the scope or intent is. The original report
 was about honoring a base-system make setting in pkgsrc, which (taken
 narrowly) is a bad idea, but for that purpose we have devel/cpuflags
 now and I think the original request is long satisfied.

 There's then some further discussion that seems to be about possible
 ways of tagging specially-built binary packages, including some
 infrastructure patches that are also now old enough to vote and almost
 certainly impossible to merge.

 My inclination would be to create a project page in the wiki about
 binary package variant tagging (if there isn't one already, I might
 have already written one years back), reference the material here
 there so it can be found again, then close this PR as the original
 request is handled.

 Note that tagging binary packages for variant compiler options is a
 special case and the problem really needs a general solution. (Other
 things that binary package tagging should handle include option
 settings, choice of compiler, native vs. pkgsrc X11, PREFER_PKGSRC
 settings, choice of security mitigations/theater...)

 Ideally it would be possible to have different variant builds of the
 same package in the same binary package repo so users can pick what
 they want. We've settled on a world where all this stuff is unlabelled
 and each package repo is expected to be self-consistent; it works
 adequately well but isn't as flexible as one might like.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.