Date: Sun, 10 Nov 1996 20:02:01 -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.961110194453.18609B-100000@protocol.eng.umd.edu> In-Reply-To: <29164.847672917@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Nov 1996, Jordan K. Hubbard wrote: > > Well, that is what I was slowly getting at. The process of making a > > particular flavor really has to start just after the extract, so that it > > gets patched and configured correctly. You'll agree that this isn't just > > Actually, the actual file names are *permuted* by the flavor via a > hashing method, so when you extract all files of a certain flavor > you're really getting hits on generic or flavor-specific versions > of whichever target you're looking for. > > > 1) New target "optionlist" that lists build options for a port, with short > > descriptions of what they mean. > > 2) New variable OPTIONS that can be set to any value specified when you > > run optionlist, to force the port to build that way. > > I'm not exactly sure I understand what problem this is designed to solve. Example: David O'Brien's vim and gvim ports. They're exactly the same software base, which is the vim editor. I would suggest that there could have been just one port, if there was a method to give options for the user, and a method to discriminate amongst packages built for that port, so that another user would know if they were getting the one that used the X11 libs or not. Such could not be reasonably done after the port is built, because the configuration phase of the build goes differently if the X11 stuff is brought in or not. David's method of handling this was the best available, but it increases the confusion level, IMO. I want a method to alert the user that ports have options. Many more ports would allow options if they could only find a reasonable method of handling them. The two biggest reasons that ports-makers don't set up options unless there is no other way out is because the method for handling options is non-standardized and doesn't allow non-interactive building, and because no one knows how to handle package building with multiple conflicting options. I want to have some kind of general option handling method of ports, and I want that method to safely extend to package building. The only way to have it extend safely to package-building is to tie package building more directly to the earlier phases of the build process, otherwise a ports-writer cannot guarantee that a package with a certain name actually has a certain set of characteristics. 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? > > > 3) name of workdir changed, so that it reflects the option list that was > > active (or maybe a new cookie deposited to tell that). > > See above. :-) > > > 4) Packages that are built for a particular option list cookie, so that > > a ports designer could lay out obvious options (like GUI and non-GUI > > packages for emacs). > > 5) PLISTs for each option. Extend PLIST name to PLIST.option_name. > > I'd have to have more details before I'd really understand what it is > you're getting at, but all I can really say is that if you're thinking > of permuting the current package tools into this, you should probably > save your hair and forget it. ;-) > > I think that the ports collection will eventually have pkg/ > directories with significantly different contents than they do now, > some perl hack doing a midnight conversion job on the current stuff at > some point in the future, once the new format is well known and > tested. > > Jordan > ----------------------------+----------------------------------------------- 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.961110194453.18609B-100000>