okay to .include "${PORTSDIR}/Mk/bsd.java.mk"?

[Sam Lawrance]

On Sun, 2004-06-20 at 19:35, Oliver Eikemeier wrote:
> Am Sonntag den, 20. Juni 2004, um 10:27, schrieb Sam Lawrance:
> 
> > I'm porting postgis which includes a set of Java classes related to
> > spatial data types (the rest of the source is C).
> >
> > I would like to provide an OPTIONS line giving the user the choice
> > whether to build those classes (WITH_JDBCTYPES).
> >
> > Problem is, after including bsd.port.pre.mk to get the OPTIONS generated
> > value of WITH_JDBCTYPES, USE_JAVA has already been read.
> >
> > Is this okay as a workaround?
> >
> > .if defined(WITH_JDBCTYPES)
> > USE_JAVA=	1.4+
> > .include "${PORTSDIR}/Mk/bsd.java.mk"
> > .endif
> 
> Please don't. It's just another hack around bugs in bsd.port.mk that 
> might
> break things when they are fixed. Either don't use OPTIONS or make it an
> extra knob that isn't selectable via OPTIONS (like in textproc/libxml2).
> 
> While this might work, you assume that it is fine to include bsd.java.mk
> after bsd.port.pre.mk, which may not be the case or may break in the
> future.

Thanks, cleared that up for me.

Just looked at the thread started by Volker Stolz along similar lines
with USE_QT_VER and ports/64233.

It seems that there are two conflicting needs, neither of which are
currently met:

* ports that want to set the inputs to bsd.port.pre.mk based on
OPTIONS-generated WITH_* variables (my problem)
* ports that want to set the OPTIONS available based on the outputs of
bsd.port.pre.mk (as outlined in the PR)

ie
* OPTIONS -> (process OPTIONS) -> WITH_* -> bsd.port.pre.mk
* bsd.port.pre.mk -> (generate OPTIONS) -> (process OPTIONS) -> WITH_*

Perhaps options processing should be able to be included where it is
needed - "bsd.port.options.mk"?

In either case both scenarios at once for a single port is not currently
possible unless bsd.port.pre.mk gets fragmented into pre- and
post-OPTIONS bits (or including bsd.port.pre.mk twice is allowed :).

Hope I made sense.
-Sam.