Date: Sun, 20 Jun 2004 16:59:51 +0200
From: Oliver Eikemeier <eikemeier@fillmore-labs.com>
To: Sam Lawrance <boris@brooknet.com.au>
Cc: ports@freebsd.org
Subject: Re: okay to .include "${PORTSDIR}/Mk/bsd.java.mk"?
Message-ID: <7B355F0F-C2CA-11D8-9250-00039312D914@fillmore-labs.com>
In-Reply-To: <1087741273.1006.86.camel@dirk>
next in thread | previous in thread | raw e-mail | index | archive | help
Sam Lawrance wrote: > 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 :). I have a different approach in PR 64233: pre-include options when available. A bsd.port.options.mk would just be a hack working around the many deficiencies of OPTIONS. IMHO OPTIONS should be deprecated and replaced by something better. I would like to see a graphical configuration tool, but OPTIONS is just badly designed and hard to support, so it causes more problems than it solves. -Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7B355F0F-C2CA-11D8-9250-00039312D914>