Date: Fri, 5 May 2000 10:03:31 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Will Andrews <andrews@technologist.com> Cc: David Heller <dheller1@rochester.rr.com>, ports@FreeBSD.ORG Subject: Re: stop complaining about x11 please (was: Re: Why does PORTS SUCK so BADLY!?) Message-ID: <20000505100331.A2724@mithrandr.moria.org> In-Reply-To: <20000502075626.D392@argon.blackdawn.com>; from andrews@technologist.com on Tue, May 02, 2000 at 07:56:26AM -0400 References: <20000501101044.F24573@fw.wintelcom.net> <00b901bfb38f$e4625cd0$b8209fc0@marlowe> <20000501105116.B32172@ccsales.com> <20000501113038.I24573@fw.wintelcom.net> <20000501234432.A2998@physics.iisc.ernet.in> <20000501150045.A391@argon.blackdawn.com> <20000502004233.A3681@physics.iisc.ernet.in> <390DDE5F.69E94C2C@rochester.rr.com> <20000501221703.A73550@mithrandr.moria.org> <20000502075626.D392@argon.blackdawn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue 2000-05-02 (07:56), Will Andrews wrote: > How can we implement portconf in the least intrusive possible method ? The way I've suggested previously in the mailing lists, and in my code. There is _no_ intrusion whatsoever. Unless the port or user explicitly asks for it, it doesn't run. It doesn't run when BATCH or PACKAGE_BUILDING is set. It acts remarkably like the script in www/apache13-php3, in fact. Porters need not change _anything_ in their Makefiles. > I'm thinking of having a files/options file that is included by bsd.port.mk > to generate a set of defines that can be used by the user to add in options > at build time. Portconf can then parse said file to generate the list of > options. How this will be done is another story. How this could be done is with the example I gave. Have a file, as I've suggested, with the options in it, that gets parsed by a program, to generate a make(1) Makefile.portconf which is then sourced by bsd.port.mk. > But if done well, I think it will make a great substitute (i.e. easy to do) > for the current -DWITH[OUT,]_X hack that's in some port Makefiles. The original was simply a "CLASS:description:options", "OPTIONS:descriptions" set. The XML is there simply because that was the only comment I was given at all about the system. So, since noone was interested, I decided to learn XML. Of course, that was at least 10 months ago, when I last looked at the code. The original was much simpler. Classes are "types" of installations, and the most common will probably be "minimum" and "maximum" ports. Options may be a one-to-one map of make(1) variables to option names. Somewhere along the way, I'll remember how I defined dependencies/conflicts. > I don't think portconf belongs in ports-base, however... I think the > default method should be to use bsd.port.mk to parse files/options and > generate a dialog(1) script based on it. Maybe you could explain why doing > configuration without X installed with your ncurses version would be better. If you look at the code, and my suggestions, one would use the perl code in ports-base to do the work. Building it into bsd.port.mk is possible, but I don't see the need. bsd.port.mk is so massive already, and the code will simply get lost. Modularization makes sense. It'll probably even costs you less fork and exec()s. Doing it inside bsd.port.mk also may hide it from other applications. > But if we're going to use an XML file, why not just rewrite the whole damn > ports tree in XML? It seems like a waste to put XML files in the tree just > for portconf. Which is why I'm suggesting files/options here. (Because it > can be used by more than just portconf, at least theoretically). "portconf" is not a program. It's supposed to be a mechanism to share build-time configuration information. This is why I wrote three front-ends to it. It doesn't matter how the information is shared, so long as we share it. As I've mentioned before, the XML is only there because I got no other feedback in the past year or so of suggesting it. The idea is that since the interface is simple, any program that wants to use it, can. An graphical port builder, not entirely unlike pib, could use it in a consistent manner, without calling any external programs, simply by parsing the portconf file for the options, and displaying or selecting things however it chooses. The upcoming 'libh' could use it in many forms of fantastical ways in our new system manager. In fact, I'll probably rewrite the gtk/ncurses frontend using libh's independent UI, once it matures. (My apologies if I seem aggressive despite re-reading over this many times; the NT admins here rewired the UPS-powered circuit about 3 months ago, and it's tripped the UPS power supply twice recently. Byebye FreeBSD uptime.) Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000505100331.A2724>