From owner-freebsd-ports@FreeBSD.ORG Thu Feb 1 20:45:10 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCCB216A402 for ; Thu, 1 Feb 2007 20:45:10 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id BD46E13C474 for ; Thu, 1 Feb 2007 20:45:10 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A1ECE1A4D87; Thu, 1 Feb 2007 12:45:10 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F2B2D51341; Thu, 1 Feb 2007 15:44:58 -0500 (EST) Date: Thu, 1 Feb 2007 15:44:58 -0500 From: Kris Kennaway To: Luigi Rizzo Message-ID: <20070201204458.GB74138@xor.obsecurity.org> References: <20070201111727.B83474@xorpc.icir.org> <20070201192051.GA72926@xor.obsecurity.org> <20070201113720.D83474@xorpc.icir.org> <20070201194417.GA73296@xor.obsecurity.org> <20070201122011.B84181@xorpc.icir.org> <20070201202511.GA74029@xor.obsecurity.org> <20070201124052.D84181@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <20070201124052.D84181@xorpc.icir.org> User-Agent: Mutt/1.4.2.2i Cc: ports@freebsd.org, Kris Kennaway Subject: Re: /usr/local/share/mk ? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2007 20:45:11 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 01, 2007 at 12:40:52PM -0800, Luigi Rizzo wrote: > On Thu, Feb 01, 2007 at 03:25:11PM -0500, Kris Kennaway wrote: > > On Thu, Feb 01, 2007 at 12:20:11PM -0800, Luigi Rizzo wrote: > > > On Thu, Feb 01, 2007 at 02:44:17PM -0500, Kris Kennaway wrote: > > > > On Thu, Feb 01, 2007 at 11:37:20AM -0800, Luigi Rizzo wrote: > > > ... > > > > > Now, this may well be a one-of-a-kind case calling for an ad-hoc > > > > > solution, but if all we need is accept to use ${PREFIX}/share/mk > > > > > for third-party .mk files, this seems a better way to handle > > > > > the problem. > > > >=20 > > > > After >10 years you are apparently the first person to want such a > > > > feature, so this suggests the application is limited :) > > >=20 > > > possibly, yes. Or maybe there were other applications solved with > > > other hacks - e.g. (randomly browsing in /usr/share/mk), do the > > > following really belong there: > > >=20 > > > bsd.info.mk - building GNU Info hypertext system > > > bsd.snmpmod.mk - building modules for the SNMP daemon bs= nmpd > > >=20 > > > They don't seem to be a part of the 'base' system unlike all > > > the others. > >=20 > > ? Those are both used by components of the base. > >=20 > > > So... there is not a recursive INSTALL, maybe nobody asked for it, > > > but certainly we have a lot of replicated constructs in the > > > ports' makefiles, and some port maintainers with a lot of patience :) > >=20 > > OK, but I don't see what this has to do with your proposal. >=20 > It was a remark on "you are the first one to ask in 10 years so > maybe the application is limited". Sometimes there is a need for > a feature, but people find it easier to use some workaround rather > than asking for it. OK, but showing other unrelated areas that might benefit from some centralization doesn't support your specific proposal. > The thing with bmake is that probably nothing other than the base > system uses it - most ports use gmake for portability reasons, > so maybe there is limited need to for custom 'mk' directories... > yet if we provide one, hopefully people will start considering > using it rather than workarounds (e.g. hardwiring the common > settings in the individual Makefiles). Around here we do things the other way around: show the necessity, then add support for it. Otherwise we end up with an uncontrollable proliferation of single-use features that quickly becomes unmaintainable. Kris --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFwlFKWry0BWjoQKURAuCAAJwLhdkKGD8eWMMlYg1KkdgF4Mg1mQCeItW/ KP/DMSb2MGbrBZjuuOEhaX8= =R0KK -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd--