configuring ports via Makefile.local
eikemeier at fillmore-labs.com
Sat Jul 31 06:54:44 PDT 2004
Ion-Mihai Tetcu wrote:
> On Sat, 31 Jul 2004 14:17:46 +0200
> Oliver Eikemeier <eikemeier at fillmore-labs.com> wrote:
>> Ion-Mihai Tetcu wrote:
>>>> I even want to be able to configure ports that have absolutely no
>>>> support for optionsNG, by prasing the Makefile for WITH(OUT)_
>>>> tests Of course you will have limited funtionality, since no
>>>> explanations of the options are available. Currently the
>>>> development has been delayed, due to the localpkg breakage.
>>> Yes, a heads-up would have been nice. Does it make sense to produce
>>> patches to convert ports without OPTIONS to OPTIONS now or one
>>> should wait until optionsNG ? Does it makes sense to convert to
>>> options at all?
>> Hmmm... The stuff I'm developing is publicly available at
>> devel/portmk. A heads-up makes only sense when decisions have been
>> made, which is not the case.
> I was speaking about the localpkg change.
Ah. We are discussing this on current@, there will be a heads-up when we
have agreed on a way to proceed.
>>> Any port that uses optionsNG should behave like before when a user
>>>> choses to use other means than optionsNG to configure the port. So
>>>> it's an optional feature, but not required.
>>> My want list for options ;) contains:
>>> - have a way to output something to the user _before_ the options
>>> blue screen
>> What do you want to display? IMHO configuration should be a one-step
>> process, perhaps with an optional help file.
> Yes. The aim is to be more user friendly. There is little screen space
> so options descriptions are more that brief. Plus that I have to check
> exclusive options not to be selected after exiting options screen, so
> the user have to do a rmconfig if that happens; it would be easier just
> to output "don't select X and Y in the same time".
Some mechanism for ports to reject invalid configurations should be in
place. And of course something like a list of possibilities to choose
from. Unfortunately this implies that dialog(1) can't be used.
More information about the freebsd-ports