Date: Mon, 11 Nov 1996 18:35:52 -0500 (EST) From: Chuck Robey <chuckr@glue.umd.edu> To: Satoshi Asami <asami@FreeBSD.ORG> Cc: FreeBSD-Ports@FreeBSD.ORG Subject: Re: blt2.1 Message-ID: <Pine.OSF.3.95.961111181642.25536D-100000@maryann.eng.umd.edu> In-Reply-To: <199611110939.BAA08673@baloon.mimi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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!
----------------------------+-----------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.95.961111181642.25536D-100000>