From nobody@FreeBSD.org  Wed Sep 21 19:04:41 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B49AC1065670
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 21 Sep 2011 19:04:41 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id A503D8FC18
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 21 Sep 2011 19:04:41 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p8LJ4fJP031329
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 21 Sep 2011 19:04:41 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p8LJ4fh9031328;
	Wed, 21 Sep 2011 19:04:41 GMT
	(envelope-from nobody)
Message-Id: <201109211904.p8LJ4fh9031328@red.freebsd.org>
Date: Wed, 21 Sep 2011 19:04:41 GMT
From: Richard Neese <r.neese@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: port fix to build on nanobsd
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         160877
>Category:       ports
>Synopsis:       port fix to build audio/cmt on nanobsd
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bf
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          update
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 21 19:10:08 UTC 2011
>Closed-Date:    Sat Nov 19 10:47:13 UTC 2011
>Last-Modified:  Sat Nov 19 10:47:13 UTC 2011
>Originator:     Richard Neese
>Release:        FreeBSD 8.2-STABLE
>Organization:
>Environment:
FreeBSD ports.freebsd.org 8.2-STABLE-201105 FreeBSD 8.2-STABLE-201105 #0: Tue May 17 05:46:49 UTC 2011     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
this patch allows for cmt port to compile for nano bsd.
>How-To-Repeat:

>Fix:


Patch attached with submission follows:

Index: Makefile
===================================================================
RCS file: /home/ncvs/ports/audio/cmt/Makefile,v
retrieving revision 1.13
diff -u -r1.13 Makefile
--- Makefile	14 Apr 2011 07:24:38 -0000	1.13
+++ Makefile	21 Sep 2011 18:33:34 -0000
@@ -21,6 +21,7 @@
 BUILD_WRKSRC=	${WRKDIR}/${PORTNAME}/src
 
 USE_GMAKE=	yes
+MAKE_ENV+=	TARGET_ARCH=
 MAKEFILE=	makefile
 MAKE_ARGS=	CXX="${CXX}" \
 		CXXFLAGS="${CXXFLAGS} -fPIC -I${LOCALBASE}/include"


>Release-Note:
>Audit-Trail:

From: Richard E Neese <r.neese@gmail.com>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc:  
Subject: Re: misc/160877: port fix to build on nanobsd
Date: Wed, 21 Sep 2011 15:10:51 -0400

 please reassign to ports
 
Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Sep 21 21:01:48 UTC 2011 
Responsible-Changed-Why:  
ports PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=160877 
Responsible-Changed-From-To: freebsd-ports-bugs->bf 
Responsible-Changed-By: bf 
Responsible-Changed-When: Thu Sep 22 10:27:40 UTC 2011 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=160877 

From: Garrett Cooper <yanegomi@gmail.com>
To: bug-followup@FreeBSD.org, r.neese@gmail.com
Cc:  
Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
Date: Wed, 26 Oct 2011 16:18:07 -0700

     I'd like to know how you're building stuff with nanobsd, because I
 had to go through quite a few tricks to get things to work (but it
 works properly with nanobsd once you apply those tricks and I haven't
 had to hack nanobsd -- yet).
     See: http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/nanobsd/common?r1=8092&r2=8193
 as an example (but note some of the newer revisions too).
 Thanks,
 -Garrett

From: "b. f." <bf1783@googlemail.com>
To: Garrett Cooper <yanegomi@gmail.com>
Cc: bug-followup@FreeBSD.org, crees@FreeBSD.org, hrs@FreeBSD.org, 
	garga@FreeBSD.org, ohauer@FreeBSD.org, autotools@FreeBSD.org, mm@FreeBSD.org, 
	imp@FreeBSD.org, portmgr@FreeBSD.org
Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
Date: Wed, 26 Oct 2011 21:21:44 -0400

 On 10/26/11, Garrett Cooper <yanegomi@gmail.com> wrote:
 > The following reply was made to PR ports/160877; it has been noted by GNATS.
 >
 > From: Garrett Cooper <yanegomi@gmail.com>
 > To: bug-followup@FreeBSD.org, r.neese@gmail.com
 > Cc:
 > Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
 > Date: Wed, 26 Oct 2011 16:18:07 -0700
 >
 >      I'd like to know how you're building stuff with nanobsd, because I
 >  had to go through quite a few tricks to get things to work (but it
 >  works properly with nanobsd once you apply those tricks and I haven't
 >  had to hack nanobsd -- yet).
 >      See:
 > http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/nanobsd/common?r1=8092&r2=8193
 >  as an example (but note some of the newer revisions too).
 
 Why are the FreeNAS scripts defining TARGET_ARCH when dealing with
 ports/packages?  This variable shouldn't be set when building
 packages, because it breaks many builds. The fact that this is done in
 FreeNAS scripts and in some other examples posted on the web seems to
 be setting a bad example for others:  there have been a slew of PRs
 (see below, for a sample -- especially 158013) from people who are
 mistakenly polluting their package build environment with this
 variable, and then demanding that ad hoc fixes be implemented in
 individual ports, which is a real pain.  We should not -- indeed,
 cannot -- be cluttering up random ports with workarounds for every
 unneeded variable that may be set by a user.  If TARGET_ARCH is
 considered to be exceptional in some sense, because users are more
 likely to set it in a mistaken analogy with cross-building in the base
 system, or because it is used in nanobsd, and it is thought that we
 need some active measures to prevent TARGET_ARCH pollution, then these
 measures should be in a central Makefile, not scattered throughout the
 Ports tree.
 
 cf. PRs:
 
 147853
 151224
 156607
 157457
 157479
 157512
 158013*
 160877
 160885
 160888
 
 Regards,
 
 b.

From: Warner Losh <imp@bsdimp.com>
To: bf1783@gmail.com
Cc: Garrett Cooper <yanegomi@gmail.com>, bug-followup@freebsd.org,
        crees@freebsd.org, hrs@freebsd.org, garga@freebsd.org,
        ohauer@freebsd.org, autotools@freebsd.org, mm@freebsd.org,
        imp@freebsd.org, portmgr@freebsd.org
Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
Date: Wed, 26 Oct 2011 21:07:04 -0600

 On Oct 26, 2011, at 7:21 PM, b. f. wrote:
 
 > On 10/26/11, Garrett Cooper <yanegomi@gmail.com> wrote:
 >> The following reply was made to PR ports/160877; it has been noted by =
 GNATS.
 >>=20
 >> From: Garrett Cooper <yanegomi@gmail.com>
 >> To: bug-followup@FreeBSD.org, r.neese@gmail.com
 >> Cc:
 >> Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
 >> Date: Wed, 26 Oct 2011 16:18:07 -0700
 >>=20
 >>     I'd like to know how you're building stuff with nanobsd, because =
 I
 >> had to go through quite a few tricks to get things to work (but it
 >> works properly with nanobsd once you apply those tricks and I haven't
 >> had to hack nanobsd -- yet).
 >>     See:
 >> =
 http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/nanobsd/common?r1=3D=
 8092&r2=3D8193
 >> as an example (but note some of the newer revisions too).
 >=20
 > Why are the FreeNAS scripts defining TARGET_ARCH when dealing with
 > ports/packages?
 
 We're defining it always inside of nanobsd when cross building.  We try =
 to build everything with the same environment, but if there are certain =
 things that are different between /usr/ports and /usr/src, then I can =
 cope.
 
 > This variable shouldn't be set when building
 > packages, because it breaks many builds. The fact that this is done in
 > FreeNAS scripts and in some other examples posted on the web seems to
 > be setting a bad example for others:  there have been a slew of PRs
 > (see below, for a sample -- especially 158013) from people who are
 > mistakenly polluting their package build environment with this
 > variable, and then demanding that ad hoc fixes be implemented in
 > individual ports, which is a real pain.  We should not -- indeed,
 > cannot -- be cluttering up random ports with workarounds for every
 > unneeded variable that may be set by a user.  If TARGET_ARCH is
 > considered to be exceptional in some sense, because users are more
 > likely to set it in a mistaken analogy with cross-building in the base
 > system, or because it is used in nanobsd, and it is thought that we
 > need some active measures to prevent TARGET_ARCH pollution, then these
 > measures should be in a central Makefile, not scattered throughout the
 > Ports tree.
 
 What's the right way to cross build ports?
 
 Warner
 
 
 
 
 > cf. PRs:
 >=20
 > 147853
 > 151224
 > 156607
 > 157457
 > 157479
 > 157512
 > 158013*
 > 160877
 > 160885
 > 160888
 >=20
 > Regards,
 >=20
 > b.
 >=20
 >=20
 

From: "b. f." <bf1783@googlemail.com>
To: Garrett Cooper <yanegomi@gmail.com>
Cc: bug-followup@freebsd.org, crees@freebsd.org, hrs@freebsd.org, 
	garga@freebsd.org, ohauer@freebsd.org, autotools@freebsd.org, mm@freebsd.org, 
	imp@freebsd.org, portmgr@freebsd.org
Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
Date: Thu, 27 Oct 2011 00:01:35 -0400

 On 10/26/11, Warner Losh <imp@bsdimp.com> wrote:
 > The following reply was made to PR ports/160877; it has been noted by GNATS.
 >
 > From: Warner Losh <imp@bsdimp.com>
 
 >
 >  What's the right way to cross build ports?
 
 As far as I know, we've never guaranteed that they could be
 cross-built.  But some users have had success building large numbers
 of packages for i386 in tinderboxes on amd64, for example.  For those
 builds, the users usually specify ARCH, MACHINE_ARCH, UNAME_m,
 UNAME_p, and occasionally CPUTYPE.  Probably a few people have
 experience with powerpc64/powerpc32, etc., but we'd have to consult
 the others.
 
 b.

From: Warner Losh <imp@bsdimp.com>
To: bf1783@gmail.com
Cc: Garrett Cooper <yanegomi@gmail.com>, bug-followup@FreeBSD.org,
        crees@FreeBSD.org, hrs@FreeBSD.org, garga@FreeBSD.org,
        ohauer@FreeBSD.org, autotools@FreeBSD.org, mm@FreeBSD.org,
        imp@FreeBSD.org, portmgr@FreeBSD.org
Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
Date: Wed, 26 Oct 2011 23:31:22 -0600

 On Oct 26, 2011, at 10:01 PM, b. f. wrote:
 
 > On 10/26/11, Warner Losh <imp@bsdimp.com> wrote:
 >> The following reply was made to PR ports/160877; it has been noted by =
 GNATS.
 >>=20
 >> From: Warner Losh <imp@bsdimp.com>
 >=20
 >>=20
 >> What's the right way to cross build ports?
 >=20
 > As far as I know, we've never guaranteed that they could be
 > cross-built.  But some users have had success building large numbers
 > of packages for i386 in tinderboxes on amd64, for example.  For those
 > builds, the users usually specify ARCH, MACHINE_ARCH, UNAME_m,
 > UNAME_p, and occasionally CPUTYPE.  Probably a few people have
 > experience with powerpc64/powerpc32, etc., but we'd have to consult
 > the others.
 
 FreeNAS builds lots of ports like that.  But all those kludges are just =
 that: kludges.
 
 In the past, I've hacked the ports system to honor TARGET_ARCH, et al =
 and it isn't that hard to get 2 of the three classes of ports.  Trivial =
 ports can be cross built with just pointing CC, et al, at the right =
 toolchain (which can either be make buildworld or make xdev).  Ports =
 that grok cross building will work if you've installed a toolchain with =
 make xdev.  The third class is ports that try to implement cross =
 building, but do it wrong.  There's no hope for those ports.
 
 There's a number of ports that are in the third class that can be made =
 to work with small tweaks to Makefiles in the tree.  They can't be done =
 centrally because the nature of the tweaks are very port specific.
 
 Warner=

From: Mark Linimon <linimon@lonesome.com>
To: Warner Losh <imp@bsdimp.com>
Cc: bf1783@gmail.com, Garrett Cooper <yanegomi@gmail.com>,
	bug-followup@freebsd.org, crees@freebsd.org, hrs@freebsd.org,
	garga@freebsd.org, ohauer@freebsd.org, autotools@freebsd.org,
	mm@freebsd.org, imp@freebsd.org, portmgr@freebsd.org
Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
Date: Thu, 27 Oct 2011 01:49:24 -0500

 On Wed, Oct 26, 2011 at 09:07:04PM -0600, Warner Losh wrote:
 > What's the right way to cross build ports?
 
 Often talked about, often desired, never solved.
 
 Frankly I think you know more about it than anyone else :-/ and thus
 would appreciate your advice.
 
 mcl

From: "b. f." <bf1783@googlemail.com>
To: Garrett Cooper <yanegomi@gmail.com>
Cc: bug-followup@freebsd.org, crees@freebsd.org, hrs@freebsd.org, 
	garga@freebsd.org, ohauer@freebsd.org, autotools@freebsd.org, mm@freebsd.org, 
	imp@freebsd.org, portmgr@freebsd.org
Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
Date: Thu, 27 Oct 2011 04:10:38 -0400

 On 10/27/11, Warner Losh <imp@bsdimp.com> wrote:
 
 >  >> What's the right way to cross build ports?
 ...
 >  > As far as I know, we've never guaranteed that they could be
 >  > cross-built.  But some users have had success building large numbers
 >  > of packages for i386 in tinderboxes on amd64, for example.  For those
 >  > builds, the users usually specify ARCH, MACHINE_ARCH, UNAME_m,
 >  > UNAME_p, and occasionally CPUTYPE.  Probably a few people have
 >  > experience with powerpc64/powerpc32, etc., but we'd have to consult
 >  > the others.
 >
 >  FreeNAS builds lots of ports like that.  But all those kludges are just =
 >  that: kludges.
 
 Yes.  We've been more intent on trying to keep the ports working for
 native builds on a few common architectures.
 
 ...
 
 >  There's a number of ports that are in the third class that can be made =
 >  to work with small tweaks to Makefiles in the tree.  They can't be done =
 >  centrally because the nature of the tweaks are very port specific.
 
 I'm sure that many people would welcome an effort to make
 cross-building easier, but until we have an organized, documented
 effort underway (projects like FreeNAS might be able to help with
 this, and we are still looking forward to simplifications from
 Warner's alternative toolchain project), with a means of testing
 changes, and can distinguish between what necessary changes can be
 made centrally, rather than in many different individual ports, then I
 suggest that we avoid these piecemeal patches in the main Ports tree
 -- in particular, in this case.
 
 b.
State-Changed-From-To: open->closed 
State-Changed-By: bf 
State-Changed-When: Sat Nov 19 10:47:12 UTC 2011 
State-Changed-Why:  
duplicate of ports/158013 

http://www.freebsd.org/cgi/query-pr.cgi?pr=160877 
>Unformatted:
