OPTIONS handling doesn't seem to work fully in dependencies anymore

[John Baldwin]

So I upgraded my desktop machine at home from 6.x -> 7.x this weekend.  As 
part of that I do my usual (albeit archaic) practice of just deleting all 
packages and rebuilding everything from ports.  I also decided to try out 
kde4 instead of kde3.  I "discovered" during this process that ports that 
were built as dependencies no longer pop up the dialog box to set OPTIONS, 
etc. during a build.  Only the "top-level" port does so.  I'm curious if this 
is a bug or a feature?  I think it might be a bug.  I'm not super familiar 
with bsd.port.mk, but I think that this bit of the Makefile might cause this 
behavior:

################################################################
#
# Do preliminary work to detect if we need to run the config
# target or not.
#
################################################################
.if (!defined(OPTIONS) || defined(CONFIG_DONE) || \
        defined(PACKAGE_BUILDING) || defined(BATCH))
_OPTIONS_OK=yes
.endif

...

.for target in extract patch configure build install package

.if !target(${target}) && defined(_OPTIONS_OK)
${target}: ${${target:U}_COOKIE}
.elif !target(${target})
${target}: config-conditional
        @cd ${.CURDIR} && ${MAKE} CONFIG_DONE=1 ${__softMAKEFLAGS} 
${${target:U}
_COOKIE}
.elif target(${target}) && defined(IGNORE)
.endif

I think this has the side effect that 'CONFIG_DONE=1' is passed to the make 
invocations used to build dependencies via the MAKEFLAGS environment 
variable, so dependency ports always have CONFIG_DONE set from the get go.  
Thus, they never invoke the config-conditional target.  My guess is that the 
intention was that this CONFIG_DONE wasn't supposed to "leak" from a port to 
its depencies, but I think that is what is happening.

-- 
John Baldwin