Date: Fri, 5 May 2000 11:00:14 -0400 From: Will Andrews <andrews@TECHNOLOGIST.COM> To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: Will Andrews <andrews@TECHNOLOGIST.COM>, 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: <20000505110014.O1642@argon.blackdawn.com> In-Reply-To: <20000505164157.A7043@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Fri, May 05, 2000 at 04:41:57PM %2B0200 References: <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> <20000505100331.A2724@mithrandr.moria.org> <20000505101401.I1642@argon.blackdawn.com> <20000505164157.A7043@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 05, 2000 at 04:41:57PM +0200, Neil Blakey-Milner wrote:
> > But why pick a language like xml instead of make macros to express the
> > options for portconf?
>
> I don't think make(1) is the easiest way, that's all. If you can find
> me an easy interface to make(1) variables from an external program
> without running 'make SEPARATOR=----====----- -V MAKEVAR -V SEPARATOR -V
> MASTER_SITES -V SEPARATOR -V FOO' ;)
You are probably right anyway.. the compromise would have to be between
Mk/* and portconf (in terms of parsing code complexity).
> > That is what I mean by intrusion - the XML files required to
> > work with portconf would become part of the repository, and since I'm not
> > sure how many people would use them, I'm not sure it's a totally awesome
> > idea. So I'd like to combine the portconf and "optional dependencies"
> > ideas, as I've said previously.
>
> They're basically doing the same thing, letting you set make variables
> in a useful way. portconf is the way of showing what variables are
> available, "optional dependencies" is what happens when you set them.
> "optional dependencies" also means what happens when you set "NNTP_ONLY"
> in ports/news/tin and so forth. portconf needs to be simplified, since
> before my concern was to limit the work for porters, and now my concern
> is a simplistic interface. Because things suddenly got complex with
> ports with WITH{,OUT}_* and define checks, I'm more happy to do a lot
> less work in portconf, and let the porters do the work in their
> Makefiles.
I'm not sure what you're trying to say here. Are you saying you don't see
the link between portconf and the "optional dependencies" ideas?
Because portconf would parse files/options (whatever language it happens to
be in, we can leave that for the implementation stage, which has partially
been completed by you), it would display these options to a user, and then
portconf would make effectual these options by passing them to make (i.e.
make -DWITH_GNOME -DWITH_GTK, etc.). make would parse files/options itself
and do the actual hooking. In this manner, we can allow people to have a
choice in the interface they use for selecting (and effecting) options on a
ports. I think files/options also simplifies things (i.e. separate the
options from the Makefile, which makes it look ugly) for people who make
and maintain ports.
> I'll simplify portconf to a bare bones on Monday, since I have African
> Network Operators Group meetings this weekend. (:
*grin* Go get 'em, tiger! :-)
> .if exists(FILENAME)
> .include FILENAME
> .endif
>
> ;)
Bah!
> > Well if we CAN use XML to generate the make-macros needed for using the
> > options on the command line, then by all means I'll be glad to help write
> > the code for this.
>
> Actually, this might be an easier way to do it. Because portconf is
> simply a means of setting variables now, we need only pass them via the
> command line to make. I like the separate file idea, though, since it
> makes it easier for other interfaces to customizing ports.
Exactly!! I'm glad we're on the same page now! :-))
> > If you aren't going to put portconf code in bsd.port.mk and you aren't
> > going to require any modifications of a port's Makefile, then how the hell
> > is portconf going to get called in the first place???
>
> Modify bsd.port.mk to run the perl script, and keep the perl separate.
Okay, I'll fly for that. So you're saying that we'll have a perl script in,
say, Mk/bsd.portconf.pl, and whenever there's a ${OPTIONS} (which will be
files/options to bsd.port.mk) file, execute the perl script to generate a
Makefile.portconf, which will then be included by the port that requires
it. I don't think it should be included by bsd.port.mk, actually, because a
port may have dependencies that have their own ${OPTIONS} and thus a
generated Makefile.portconf should be local to a port, not made global
through bsd.port.mk. :-)
> Actually, if portconf becomes as simple as I think it can be made, it
> can be done in sh in bsd.port.mk for the simple case, and any other
> interfaces can be defined as necessary.
*nod*
> portconf was never meant to be an application, just an attempt at
> user-friendliness and an interface to options that are otherwise hidden
> away from users.
Well, things change. ;-)
--
Will Andrews <andrews@technologist.com>
GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+
G++>+++ e->++++ h! r-->+++ y?
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?20000505110014.O1642>