From owner-freebsd-ports@FreeBSD.ORG Mon Nov 16 11:09:33 2009 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EFA41065696 for ; Mon, 16 Nov 2009 11:09:33 +0000 (UTC) (envelope-from freebsduser@paradisegreen.co.uk) Received: from mail.paradisegreen.co.uk (almaz.paradisegreen.co.uk [81.187.228.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7BDCB8FC2C for ; Mon, 16 Nov 2009 11:09:31 +0000 (UTC) Received: from [10.0.0.6] (vaio.paradise [10.0.0.6]) by mail.paradisegreen.co.uk (8.13.3/8.13.3) with ESMTP id nAGB9Sgi049797 for ; Mon, 16 Nov 2009 11:09:29 GMT (envelope-from freebsduser@paradisegreen.co.uk) DomainKey-Signature: a=rsa-sha1; s=default; d=paradisegreen.co.uk; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:content-type:content-transfer-encoding; b=eeLWkB7vq4lfmXDmfwQymX/ES0rFHTfVE5eViHxLUs+beKNcoLZB8fSdPaNPDNz7M MvomFgM9wK3hiudH9tGhA== Message-ID: <4B0132E2.3020504@paradisegreen.co.uk> Date: Mon, 16 Nov 2009 11:09:22 +0000 From: Thomas Sandford User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ports@freebsd.org References: <4AF897A4.3070408@delphij.net> <20091109225232.GA34294@lor.one-eyed-alien.net> <4AF9B6CC.5090308@delphij.net> <20091113011000.GA45256@atarininja.org> <20091113200607.GA59749@atarininja.org> <4AFED0D3.2050403@paradisegreen.co.uk> <20091115204818.GA57571@server.vk2pj.dyndns.org> In-Reply-To: <20091115204818.GA57571@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VERIFIED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on almaz.paradisegreen.co.uk Cc: Subject: Re: RFC: svn for make fetch 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: Mon, 16 Nov 2009 11:09:33 -0000 Peter Jeremy wrote: > On 2009-Nov-14 15:46:27 +0000, Thomas Sandford wrote: >> Wesley Shields wrote: >>> Sure, but it doesn't belong in bsd.*.mk. Turn it into a script and >>> submit it as a regular port. >> ... >> Surely the whole value/purpose of the ports build infrastructure is to >> present a consistent way of doing things rather than different >> maintainers doing their own thing and solving problems in different, and >> quite possibly sub-optimal ways and/or bloating multiple individual port >> Makefiles with what could be kept in a single bsd.*.mk file. > > If it affected several hundred ports and/or was visible to the end > user then this might be justification for embedding it into bsd.*.mk. > > The ports build infrastructure is already quite large (>20K LOC) and > difficult to follow. The overheads associated with loading bsd.*.mk > files also makes operations like "make index" very time-consuming. > IMHO, bloating it further to marginally simplify life for the > maintainers of ~15 ports is not a good tradeoff. > > Wesley's suggestion above sounds like the best solution. > >> And if the file were (say) bsd.vcs.mk and were pulled in only if one of >> >> USE_SVNFETCH >> USE_CVSFETCH >> USE_GITFETCH >> >> etc were defined then the impact of the bloat on other ports is minimal. > > If you still want to go this way, I'd suggest writing a stand-alone > bsd.vcs.mk that can be .include'd by the port when it needs the > functionality. Personally I think the performance difference between .ifdef USE_SVNFETCH .include "${PORTSDIR}/Mk/bsd.vcs.mk" .endif in bsd.port.mk and only explicitly including it in the ports that use it is marginal, but I could certainly live with this as a compromise. -- Thomas Sandford