Date: Wed, 06 Oct 2010 23:22:38 -0400 From: jhell <jhell@DataIX.net> To: obrien@freebsd.org Cc: David DEMELIER <demelier.david@gmail.com>, FreeBSD Ports <ports@freebsd.org>, "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> Subject: Re: OPTIONS Message-ID: <4CAD3CFE.8030700@DataIX.net> In-Reply-To: <20101006175513.GB81751@dragon.NUXI.org> References: <AANLkTik%2B1rvY4ZYgzHRjaX8PBfD1UqNCNeadHqg3KBfo@mail.gmail.com> <20100918223933.GB85995@dragon.NUXI.org> <AANLkTi=vPKpaPL9L=pQN9EdWdEN3sf1pos6uGtJU7ybV@mail.gmail.com> <20101002002605.GA8018@dragon.NUXI.org> <AANLkTinkasFFQ8ssbTSdbYUS%2BJ-tYMc1U3w9rkUCk9Gd@mail.gmail.com> <4CA844E5.7060303@infracaninophile.co.uk> <AANLkTimLqUaZMyDs-mhc-cQbASU%2B_1XqRjd=2=N%2BVSsR@mail.gmail.com> <20101005183452.GF7829@dragon.NUXI.org> <20101006084040.GA53569@dragon.NUXI.org> <AANLkTi=nH9xMMiiAV2y8YP=KH8-SRF1COXnUSkZUUvMc@mail.gmail.com> <20101006175513.GB81751@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/06/2010 13:55, David O'Brien wrote:
> On Wed, Oct 06, 2010 at 12:01:48PM +0300, Andrew W. Nosenko wrote:
>> On Wed, Oct 6, 2010 at 11:40, David O'Brien <obrien@freebsd.org> wrote:
>>> On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote:
>>>>> 2010/10/3 Matthew Seaman <m.seaman@infracaninophile.co.uk>:
>>>>>> In fact, you might just as well write a small HTML form, display it
>>>>>> using lynx or w3c or some other text mode browser[*], and then have the
>>>>>> form action feed into a CGI program that outputs a small Makefile with
>>>>>> appropriate variable definitions in it.
>>>>
>>>> I like this statement -- as it shows just how complex this will get when
>>>> taken to its natural conclusion.
>>>
>>> This is also how ridiculous things can get:
>>>
>>> curl 7.21.1 now offers me:
>>> � �[X] WERROR � � � Treat compilation warnings as errors
>>>
>>> � �Can the port maintainer really not decide if that should just be
>>> � �turned off or turned on for FreeBSD?!?
>>
>> I wonder why -Werror even ever considered to be turned "on" at all.
>
> \AOL{me too}
>
> I mean building with "-Werror" sounds like goodness -- of course I
> want it.
>
> But why is the maintainer offering me a choice?
> What is the likelihood of the port not building with -Werror?
> Does he know of versions of FreeBSD where the port will not build
> with -Werror? Hum.. maybe I don't want -Werror. But then why didn't
> the the maintainer just decide we would all not build with -Werror?
>
> Given we are just building and installing Curl, what do we expect
> users to do choose WERROR and get a build break with -Werror?
> They aren't developing the next version of Curl. Can they submit a
> FreeBSD PR and expect the maintainer will quickly add a patch to the
> port to fix the warning(s)? Or will the response be
> "Well, don't do that."? In which case just turning off -Werror for
> all seems a better thing to do.
>
IMHO If I may, The OPTIONS framework is a UI(User Interface) to useful
options that a 'User' would be interested in turning on. This would be
things that a user, not a 'developer' could use or would find helpful.
With the above said, if it was the developers intent to add options in
order to make debugging the port easier for them, then I feel that is
the wrong approach as these are options that are more appropriately
handled by CFLAGS CXXFLAGS LDFLAGS and such since they are developer
centric and mean very little to the majority of the community.
Now with both of the above stated, it may be useful if specific
developer options were wrapped in a statement that would check to see if
a MAINTAINER_MODE has been defined allowing those options to be
dynamically added to the list of existing option.
Personally I feel that because of the loose guidelines that we already
have in the Porters Handbook that when frameworks like this present
problems as the options framework has already shown, that a better
defined standard should be developed & agreed upon so that every
developer and user knows exactly what to expect out of every port and
what is expected to be presented to the user. A ports tree of this size
and not having a clear and set-forth standard as to what can be expected
is fairly hazardous IMO. If I had missed an area 'one area' where this
is already defined then please excuse me and reference me a clear link.
Regards,
--
jhell,v
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CAD3CFE.8030700>