From owner-freebsd-ports@FreeBSD.ORG Thu May 4 19:23:30 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 888A416A4C9 for ; Thu, 4 May 2006 19:23:30 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCFC943D6A for ; Thu, 4 May 2006 19:23:09 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k44JN8QC011173; Thu, 4 May 2006 12:23:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k44JN8Et011172; Thu, 4 May 2006 12:23:08 -0700 Date: Thu, 4 May 2006 12:23:08 -0700 From: Brooks Davis To: Kris Kennaway Message-ID: <20060504192308.GE28973@odin.ac.hmc.edu> References: <44538D42.8030301@chrismaness.com> <200605010901.50654.aren.tyr@gawab.com> <20060501091523.GA38820@pentarou.parodius.com> <200605021827.34873.aren.tyr@gawab.com> <20060504094155.GC984@roadrunner.q.local> <20060504165727.GA67780@xor.obsecurity.org> <20060504183936.GC28973@odin.ac.hmc.edu> <20060504191512.GA69895@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rgf3q3z9SdmXC6oT" Content-Disposition: inline In-Reply-To: <20060504191512.GA69895@xor.obsecurity.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Brooks Davis , freebsd-ports@freebsd.org Subject: Re: Upgrade Tool 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, 04 May 2006 19:23:30 -0000 --Rgf3q3z9SdmXC6oT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 04, 2006 at 03:15:12PM -0400, Kris Kennaway wrote: > On Thu, May 04, 2006 at 11:39:36AM -0700, Brooks Davis wrote: > > On Thu, May 04, 2006 at 12:57:27PM -0400, Kris Kennaway wrote: > > > On Thu, May 04, 2006 at 11:41:55AM +0200, Ulrich Spoerlein wrote: > > > > Aren Olvalde Tyr wrote: > > > > > Perhaps it would be good, if, say on the corresponding port entry= on the=20 > > > > > FreeBSD ports webpage, it listed all the options used for buildin= g the binary=20 > > > > > package. For example, for the "Package" link, instead of simply l= inking to=20 > > > > > the package, it could link to a page entry listing all of the bui= ld options=20 > > > > > used, with the package download link at the bottom. Or something = like that.=20 > > > > >=20 > > > > > Just an idea. What do people think?=20 > > > >=20 > > > > I'd even go further. This is something I have been thinking about o= n and > > > > off. Namely, a FLAVOUR system for packages. A maintainer specifies = up to > > > > three FLAVOURs per port, which set various flags for building the p= ort. > > >=20 > > > In FreeBSD land these are called "slave ports", and you can have as > > > many as you like. I don't have any interest in adding a separate > > > "flavour" system in parallel to this. > >=20 > > With MPI based parallel code there are times where I think a flavor > > system might scale better, but I haven't done the work to expose the > > non-scaling yet. The problem is that we've got ~5 versions of MPI > > in the tree, but each one of those really should be buildable with > > different C and Fortran compilers so you could easily see 50+ MPIs. > > Multiple each applicaiton by that and things get crazy. :) >=20 > Do all combinations really need packages? With or without flavours > you wouldn't even think about building packages for all possible > combinations of build options for a port. All combinations don't need packages, but I'd like an easy way to build as many as half a dozen versions on the same machine so users can use the compiler and MPI version of their choice. At this point the easiest way to handle that would be to build non-conflicting slave ports for the combinations I wanted but that starts to waste a lot of inodes pretty fast. Another option that could work for me would be to make it easier to maintain a local ports category so I could have my own slave ports. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Rgf3q3z9SdmXC6oT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEWlSbXY6L6fI4GtQRAtg3AKCZvjSH8b3pkrkk1y+Gykuz6qBpZgCfWZVR jiz4YMaMGTOm+wuOSCDmfcs= =tPkE -----END PGP SIGNATURE----- --Rgf3q3z9SdmXC6oT--