2010/10/3 Matthew Seaman <m.sea...@infracaninophile.co.uk>: > On 03/10/2010 10:45:01, David DEMELIER wrote: >> 2010/10/3 Matthew Seaman <m.sea...@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: matt...@infracaninophile.co.uk Kent, CT11 9PW > > -- Demelier David _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"