Date: Mon, 11 Nov 1996 08:36:38 -0500 (EST) From: Chuck Robey <chuckr@glue.umd.edu> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Satoshi Asami <asami@FreeBSD.ORG>, FreeBSD-Ports@FreeBSD.ORG Subject: Re: blt2.1 Message-ID: <Pine.OSF.3.95.961111083006.14784A-100000@modem.eng.umd.edu> In-Reply-To: <1348.847702646@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Nov 1996, Jordan K. Hubbard wrote: > > One way to do this would be to have multiple work directories, tagged with > > the option names. Another way would be to use the current single work > > directory, but to deposit a cookie in the work dir specifying the option > > set chosen during the earlier (configure and patch) build phases. > > > > I think I like the latter method better, myself. Am I making myself clear > > yet? > > Sort of, though it's still not clear to me how the "options" would > actually change the behavior of the package extraction process, or how > especially complex option handling would be done. In my new system, > the package's internal work procedures are written in secure TCL and > hence you can do quite a bit based on whether the user says "I want > the X or the non-X version of blah", something which might involve > everything from changing the internal packing list to checking an > entirely different set of dependencies. > > Just having "passive" option information would, I think, only cover > some of the bases and you'd have to make the pkg_add tool arbitrarily > complex to deal with all them. In my system, pkg_add just provides > the execution environment and is otherwise "dumb" - all the > intelligence is in the package. > > As to the creation process, you just build the port and transfer as > much of it (along with property information) into the package as is > relevant for that build. Then you rebuild the port with different > options, assuming that's called for, and add it to the *same* package > with different flavor settings. Voila, now you have one package with > two different sets of properties. Repeat as necessary, and as you > have disk space for the monster package file you're building. :) I see, we're taking orthogonal directions. Mine would have a different package for each set of options, yours would build every possible option. Mine would add intelligence to the build process (which I understand better) and leave package making where it is, yours would leave the build process where it is (with some changes, so that it builds every possible configuration to stuff into the package) and add intelligence to the unpacking. OK, if you want that direction. Do you include any hackery to allow the guy who builds his own ports just to build and install the parts he wants? ----------------------------+----------------------------------------------- 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.961111083006.14784A-100000>