From owner-freebsd-ports Mon Nov 11 15:36:11 1996 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20704 for ports-outgoing; Mon, 11 Nov 1996 15:36:11 -0800 (PST) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA20631; Mon, 11 Nov 1996 15:36:02 -0800 (PST) Received: from maryann.eng.umd.edu (maryann.eng.umd.edu [129.2.103.22]) by po1.glue.umd.edu (8.8.2/8.7.3) with ESMTP id SAA19045; Mon, 11 Nov 1996 18:35:55 -0500 (EST) Received: from localhost (chuckr@localhost) by maryann.eng.umd.edu (8.7.5/8.7.3) with SMTP id SAA25918; Mon, 11 Nov 1996 18:35:54 -0500 (EST) X-Authentication-Warning: maryann.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 11 Nov 1996 18:35:52 -0500 (EST) From: Chuck Robey X-Sender: chuckr@maryann.eng.umd.edu To: Satoshi Asami cc: FreeBSD-Ports@FreeBSD.ORG Subject: Re: blt2.1 In-Reply-To: <199611110939.BAA08673@baloon.mimi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Satoshi Asami wrote: > * Most people don't build packages, do they? I mean, we could alter the > * road from cleaned to to delivered package, without inconveniencing most > * folks, right? > > You are right. I was thinking about another variable, > PACKAGE_BUILDING, that I (and anybody elso who builds packages) should > set, which would then build the port with the "least common > denominator" (?) configuration you are talking about. > > So, for this case, it should be something like: > > .if defined(PACKAGE_BUILDING) > pre-patch: > ${CP} ${FILESDIR}/ignore-itcl-patch ${PATCHDIR}/patch-00 > pre-clean: > ${RM} ${PATCHDIR}/patch-00 > .endif > > Makes sense? Partially. It's only part of the problem, which I see as several parts: 1) some ports have options that result in radically different builds. 2) packages should refer to a certain standard and traceable set of functions, so that one knows in advance of installing a port if it will work or not, without consulting the builder. If you use the PACKAGE_BUILDING thing, then you set up some kind of standard option set that you can enforce, for packages. I want to go just a little past that. I want variable OPTIONS_LIST, which the user can query to find allowable build options. I want variable OPTIONS, which is the subset of OPTIONS_LIST that the user has chosen. I want a cookie dropped specifying the options chosen, in the work dir. The form of the OPTIONS is upper case alphanumeric, ABCD if the first 4 options are chosen, or maybe AD if the first and 4th options are chosen. (this could be numbers, but I think letters is better.) I want the package name to be automatically lengthened so that the OPTIONS value is pasted in just before the .tgz. I want PLIST changed from PLIST to PLIST.A or PLIST.AB (one for each option set possible). This means that you don't have to actually enforce the building of packages right at the start, instead you can let the world know right off the bat the exact makeup of a particular package contents. A new bsd.port.mk target should list the available options, and do it by letter. If any make phase is initiated, where the cookie dropped no longer matches the current OPTIONS variable, then the firs thing that should happen is a make clean. so that a new OPTIONS cookie can be dropped, and a clean build always enforced. I think something could and should be done to more clearly specify the meaning of the options .... I'm open to suggestion on that. My personal choice would be a new set of files in pkg, OPTION.A, OPTION.B, each with very short descrition of the use of the option indicated, hopefully just 4-6 words. I wanted to put off designing this until school was out. Won't wait? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+-----------------------------------------------