configuring ports via Makefile.local

[Oliver Eikemeier]

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.

-Oliver