From owner-freebsd-ports@FreeBSD.ORG Sat Jul 21 08:24:59 2007 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 CD8CA16A417; Sat, 21 Jul 2007 08:24:59 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 51A9C13C465; Sat, 21 Jul 2007 08:24:59 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.14.1/8.14.1) with ESMTP id l6L8OfAZ097044; Sat, 21 Jul 2007 09:24:43 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk from=m.seaman@infracaninophile.co.uk; sender-id=permerror; spf=permerror X-SenderID: Sendmail Sender-ID Filter v0.2.14 smtp.infracaninophile.co.uk l6L8OfAZ097044 Message-ID: <46A1C2C9.80704@infracaninophile.co.uk> Date: Sat, 21 Jul 2007 09:24:41 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.4 (X11/20070619) MIME-Version: 1.0 To: Doug Barton References: <46A05B21.90603@u.washington.edu> <46A0711F.2020200@infracaninophile.co.uk> <46A1068A.3010004@FreeBSD.org> In-Reply-To: <46A1068A.3010004@FreeBSD.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Sat, 21 Jul 2007 09:24:54 +0100 (BST) X-Virus-Scanned: ClamAV 0.91.1/3713/Sat Jul 21 02:18:46 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME, DKIM_POLICY_TESTING, NO_RELAYS autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on happy-idiot-talk.infracaninophile.co.uk Cc: ports@FreeBSD.org, Garrett Cooper Subject: Re: Proposal for another category in INDEX: common_deps 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: Sat, 21 Jul 2007 08:25:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Doug Barton wrote: > Matthew Seaman wrote: > >> In many ways it would be more useful to delete from the >> EXTRACT_DEPENDS, FETCH_DEPENDS, PATCH_DEPENDS, BUILD_DEPENDS[*] >> lists in the INDEX any package that also appears in the RUN_DEPENDS >> list. This leaves the four listed fields with just the extra >> packages that need to be present at build/install time. > > Everything that is needed to build the port must be in BUILD_DEPENDS. > Everything necessary to run the port must be in RUN_DEPENDS. This is > needed to support building packages on one machine, and running them > on another. In terms of what you need in port Makefiles, then yes. In terms of what goes into the INDEX, then no. I was intending only to change the format and content of the INDEX. Calling the INDEX columns by the same names as the Make variables they are (mostly) derived from has now got the the state where it is more confusing than enlightening, so thinking up different column names sounds like a good idea to me. In terms of Makefile variables, BUILD_DEPENDS has a quite specific meaning: it all the extra software that must be present at the time the 'do-build:' target in the port Makefile is reached. Of the others, (which apply analogously to the 'do-fetch:', 'do-extract:', 'do-patch:' targets.) EXTRACT_DEPENDS is used reasonably frequently, generally for ports that need unzip to extract them. Otherwise those variables tend to be empty because the base system supplies all of the necessary functionality. libarchive nowadays can unpack zips so many more of the EXTRACT_DEPENDS variables will eventually end up empty as well. Do I think the whole architecture of the ports system should be changed to eliminate most of the *_DEPENDS targets? No. Too much pain for no gain. Do I think it's worth having a separate column in the INDEX for the contents of those variables? No. >> -- and as gmake depends on >> gettext that means a very large fraction of the ports most people >> have installed. However, if the only way an application depends on >> gettext is via gmake /at build time/ then rebuilding that >> application is really not necessary. Using LIB_DEPENDS to >> distinguish ports that are linked against any particular shlib >> versus those that inherit a dependency against a shlib for other >> reasons could save rather a lot of wasted CPU cycles. > > I don't see how we need a separate LIB_DEPENDS to achieve this. Can > you describe in more detail the mechanism you have in mind? The idea was that anything in a LIB_DEPENDS target of a port would a a shared library to be linked against, and it's only the software that links against the shlib that needs to be recompiled if the shlib ABI changes. However I see on reflection that this doesn't go far enough: DSO modules have the same sort of linkage requirement, but don't get mentioned in LIB_DEPENDS Again, the idea here was not to change anything in the ports themselves: just what was presented in the INDEX, and then mainly as a resource to make easier the lives of the people that write ports management software. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGocLJ8Mjk52CukIwRCBeTAJ9YCTbgTWo9N71pssC5ZgqJO1GD/wCfUs4g NitUYwteyQDZnZ1392pAbjQ= =akvP -----END PGP SIGNATURE-----