OPTIONS

David DEMELIER demelier.david at gmail.com
Sun Oct 3 11:39:55 UTC 2010


2010/10/3 Matthew Seaman <m.seaman at infracaninophile.co.uk>:
> On 03/10/2010 10:45:01, David DEMELIER wrote:
>> 2010/10/3 Matthew Seaman <m.seaman at infracaninophile.co.uk>:
>>> On 03/10/2010 09:22:46, David DEMELIER wrote:
>>>>> 3. OPTIONS are limited to only checkbox YES/NO settings.
>>>>>> Why can I not set PREFIX thru the OPTIONS framework and have it come
>>>>>> from /var/db/ports/${PORTNAME}/options on the 2nd and later builds?
>>>>>> Even the boolean NOPORTDOCS isn't available thru OPTIONS.
>>>>>> Thus it is an inconsistent way to configure a port.
>>>>>>
>>>> I agree. As I said in 4, OPTIONS should follow the defined knob in
>>>> make.conf. But for not boolean knobs there is something we can also
>>>> do, spawn a little textbox to define an option with a string. Example
>>>> :
>>>>
>>>> [X] WITH_X foo bar
>>>> [ ] WITH_Y foo bar baz
>>>> [fr_FR en_GB] LANGS to be build
>>>>
>>>> Here pressing enter on LANGS would spawn a little textbox that can be
>>>> fulfilled by the user. The little problem is how to tell to OPTIONS
>>>> that it's not a boolean entry.
>>>>
>>>
>>> And the rest?  Pursuing this idea through to its logical conclusion,
>>> you'ld end up implementing radio buttons, text entry boxes, drop down
>>> lists -- all the normal bits used in html forms.
>>>
>>
>> Don't you like this? sysinstall was made with dialog. And radiobuttons
>> could be used to choose a group of options yes, for example when you
>> only need to choose one option in three available choices, then BROKEN
>> lines could be removed :-)
>
> Don't get me wrong -- I think the current OPTIONS processing is at once
> too limited and too intrusive, and that it is ripe for some serious
> improvement.  I'm all for your idea; I just don't think you've gone far
> enough.
>
> Now, personally, I quite like the idea of simply sticking entries into
> /etc/make.conf to control port compilation settings.  Which would be
> fine for me managing my small number of home machines, but certainly not
> suitable for all users.  There is also the problem of knowing what
> controls are available and having some reasonable idea of what they do,
> without the necessity of being a make(1) guru or grovelling through the
> guts of dozens of ports.
>

Yes that's why I would like that OPTIONS must read make.conf to set
default ports options and only after make a individual change for it.

> Giving OPTIONS processing a lot more flexibility, and the capability to
> display help text etc. (yes -- I know there have been attempts in this
> direction already) plus pushing some of the logic up from the Makefile
> into the OPTIONS dialogue[*] would certainly improve the user experience.
>
> Something with the capabilities of sysinstall would be a step in the
> right direction, but I think most would agree, sysinstall is a bit
> clunky and confusing to new users.  An alternative that behaves like a
> web form is going to be a lot more accessible to J. Random User.
>
> But that is really beyond the limits of what I have any idea about
> coding.  I can see how to prototype it readily enough as a web app, but
> having to fire up an instance of apache or something just to install a
> few ports just ain't right.
>
>        Cheers,
>
>        Matthew
>
> [*] Ever had the experience of clicking on OPTIONS settings and then
> finding the port won't accept that combination of OPTIONS?  That's
> frustrating, especially when combined with the use of eg. portmaster(8)
> where choosing OPTIONS can happen quite a while before attempting to
> build the port.
>
> --
> Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
>                                                  Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
> JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW
>
>



-- 
Demelier David


More information about the freebsd-ports mailing list