OK.. I've held off the last few days with the USE_X11 patches, and I just want
to get it either discussed, or decided on as to what we are doing with USE_X11
dependencies in the pkg tree.

The problem, as I see it.. is this:

There are four types of pkgs that need X11.

a) pkgs that install, and should[1] install in /usr/X11R6
b) pkgs that require X to build, but can be installed anywhere.
c) pkgs that use some piddly reference to X11, to compile a tiny app, and
otherwise work fine without it.
d) pkgs that can use X, if it is there, but do fine without.

Now for a.  Currently anything that uses imake falls into that category.  Due
to what I consider either a bug, or a lack of foresight in the design of
imake.. One could make an argument that things like lesstif should fall into
category a, even if they don't use imake.  I could argue against this with
great vengence, but thats a different problem.

The problem is.. we have things like faces, mm, tk80, giflib, etc etc etc. That
use X to do things, (say for example a pkg that fiddles with an X bitmap, but
never displays it, might use an X11 header file to get the defines) This stuff,
doesn't currently install into the X tree, nor should it just because it makes
some reference to X.  But if you are on a non X11 machine, it will try to build
anyway and bomb.

here is my proposal, and If i've just missed the boat, then please just tell me
what to do so I can resume my flood of PR's ;)

USE_IMAKE:      specifies the use of imake in the build.  Period.
USE_X11:        informs the user that this pkg won't build without X.
USE_XBASE:      causes the pkg to be installed in the X11R6 tree.

Thus, if you have a pkg like an old version of tcsh, that used imake, but
belongs in /usr/pkg, you would only define USE_IMAKE.

If you want it to depend on X, install in X, but its a gnu configure app or
whatever, use both USE_XBASE and USE_X11.

I really don't know what to do about case "d", where the pkg works fine either
way..  Something like xemacs comes to mind.  (a sick example...)  

Two things can be done (as far as I see) about these cases.

a: Make two pkgs, one with X enabled, one without.
b: make things really complex with a WANT_X define or something and make all
sorts of wacky conditionals to build the pkg either way if you have X installed.

B is somewhat more "elegant" to the user, but really a bear for the developer.

Things like this will come up however, and allready have.  Nethack is like this
(can do tty, X11, or qt) emacs and xemacs,  I'm sure there are more..

---
Tim Rightnour    -  root@garbled.net
http://www.zynetwc.com/~garbled/garbled.html