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

Oliver Eikemeier eikemeier at fillmore-labs.com
Sun Jun 20 23:56:54 PDT 2004

Sergey Matveychuk wrote:

> Oliver Eikemeier wrote:
>> 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.
> Does it means your PR/64233 is not appropriate?

It is a start, but it doesn't solve all problems OPTIONS has. The
major points are:

- OPTIONS has to influence ALL-DEPENDS-LIST, and as a consequence
   describe (INDEX), clean etc.

- there has to be a default mode, where virgin options are created
   (but not saved), so you could build a correct INDEX without
   generating saved OPTION for all ports

- ports need to be able to reject a certain set of OPTIONS (invalid
   combinations), so that the user has to configure again.

- a `configure-recursive' where all needed packages are configured
   (reevaluated if necessary, when dependencies change)

- a decent interface to variables given on the command line,
   so OPTIONS can play together with portupgrade and users
   don't have to guess what will happen when WITH_XXX *and*
   WITHOUT_XXX are given

- drop down/radio box support for stuff like WITH_XXX_VER

- the OPTIONS file should have either sh(1) or make(1) syntax, but
   not both.

- saved configurations need to be versioned, so that they can
   be invalidated by ports.

PR 64233 mainly addressed the point where OPTIONS are available and
some dependency issues (like influencing describe), but not all.
Many points remain still open, and when you read the mailing lists
you will realized that people are having real problems with that.


More information about the freebsd-ports mailing list