Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 May 2000 10:14:01 -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:  <20000505101401.I1642@argon.blackdawn.com>
In-Reply-To: <20000505100331.A2724@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Fri, May 05, 2000 at 10:03:31AM %2B0200
References:  <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> <20000505100331.A2724@mithrandr.moria.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 05, 2000 at 10:03:31AM +0200, Neil Blakey-Milner wrote:
> 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.

No, no. You still require an xml file to become part of the repository. But
why pick a language like xml instead of make macros to express the options
for portconf? 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.

> 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.

Hmm... so how do you get bsd.port.mk to source a file that doesn't exist
(which I assume because you say "generated") ?

> > 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.

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.

> > 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.

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???

> > 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.

Okay.. well, you know, now that I think some more about this, it seems that
XML would be fine, as long as it's possible to parse it in bsd.port.mk or
similar to allow someone who just wants to use make options (like -DWITH_X
-DWITH_GNOME -DWITH_GTK, etc.) or some other method of specifying options
for a port.

> 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.

This sounds cool..

> (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.)

Heh, I know the feeling. My machine lapsed previously due to UPS problems,
but today the 3.4-STABLE box is at:

10:12AM  up 90 days,  4:12, 9 users, load averages: 1.03, 1.10, 1.07

Neil, I think I need to restate my ideas and send them to you another time
(give me a couple weeks to think on the issue then bug me about it).

Anyway, thanks a lot for your input!! It's much appreciated!

-- 
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?20000505101401.I1642>