Nice-to-have fix for autogen.sh
Pete Batard
pete at akeo.ie
Thu Feb 2 06:32:49 EST 2012
On 2012.02.02 04:03, Segher Boessenkool wrote:
>>>> Again, it's not a matter of annoyances.
>>>
>>> "Again"? You brought it up yourself! :-)
>>
>> Quote 1 (your previous e-mail):
>> > And exactly analogously for people who find _not_ running it an
>> > annoyance!
>>
>> Quote 2 (mail before that):
>> > I don't know about you, but I do not usually want any of the options
>> > that are enabled by default (except for maintainer mode some of the
>> > time).
>
> You want quotes? Let's not quote out of context then:
Out of context?
The context is clarifying why "annoyances" is being brought up as the
subtext of your previous messages by providing relevant quotes, the
interpretation of which, and clarification as to why I believe annoyance
very much applies, you mysteriously chose to eliminate...
Or should someone not use the wording "issue" when someone speaks about
"problems" because only "problems" were mentioned in the OP?
>>>> That is not an argument for either way.
>>>
>>> Well, I think it quite restricts the scope of the people who are
>>> expected to find that having an autogen that runs configure is an
>>> annoyance.
>>
>> And exactly analogously for people who find _not_ running it an
>> annoyance!
>
> You brought up "annoyance". You might think I am annoyed with
> the current behaviour, and you might well be right
I brought it up precisely from your: "I do not usually want any of the
options that are enabled by default", which to me equates an annoyance
incurred onto you, and which will be used as the basis for the point you
intend to make. Or do you have another single word that could be used to
sum up your "I do not want" sentence? "preference" would seem a little
too mild, because of the strong "not want", but the "usually" also
indicates that it is something you can live with, so annoyance seems to
fit the bill perfectly as far as I'm concerned, whether you want to
accept the terminology or not. And yes, my interpretation of your words
then will be that you are indeed annoyed with the current behaviour.
Can you at least understand how your wording can be construed as
implying "annoyance"? Or should people not be able to interpret and use
a single word to try to summarize a previous point?
Now, with regards to the actual content of the quote, in case I haven't
made myself clear, I have to strongly disagree with your view that the
majority of users will not want a configure being run with the default
options. My differing view here is that when I start using software, and
especially if it's a cog in a larger machinery, I very much expect the
default options to be the ones that the developers established will be
the best for most people, and in a first instance, this is what I'll use
when going for a test run. It's only if I encounter issues during this
test run that I would tinker with nonstandard configure options, such as
logging, etc. I believe that most users will proceed that way, so I have
to strongly disagree on your idea that the majority of the libusbx/git
users would do otherwise.
> but if you think I base "what I
> think is best for libusbx" on "what I like best" you are dead wrong.
Indeed this is exactly what it looked like to me, because I have a
diametrically opposed view of what most users will do when getting
started with libusbx, and I don't believe you have considered the full
picture. This is based on the grounds that, given the choice of simply
trying the default options, or having to do extra to figure out custom
parameters they may want to provide (which users will actually only be
able to find after a configure has been produced), the majority of users
will go with least effort.
Even outside of least effort, it also makes a lot of sense to me to
consider that, since users will need a full fledged configure to have
been produced before they can even start looking at additional custom
options, should they have a wish to change any, we:
1. Should generate a configure by default
2. While we're at it, generate it with the options that we think will be
most beneficial for our users by default, an may alleviate their need to
proceed to further configuration. Otherwise, users will just invoke
configure, get one that doesn't enable debug logging and have to run
configure again to get it...
So, instead of this nonsense about the use of "annoyance", I would very
much prefer if your rebuttal was aimed at disproving my idea of why the
above makes more logical sense than your view (with more than "I do not
agree"). Or, if you don't want to address that, and don't provide
arguments that I can use to reconsider my current position, then we
probably will need some form of external arbitration.
> I do not fail to comprehend. I just do not agree.
And that's fine. Then we can bring the debate as to what others think
the default user behaviour will be when using libusbx/git, and what we
*collectively* think will benefit users most, which is what I tried to
do previously by clarifying the reasons why I adopted a position that is
different from yours.
> Anyway, if we switch to using autoreconf in autogen.sh, everyone
> should be happy?
Probably. I'll tell you when we get there and I have tried the new approach.
Regards,
/Pete
More information about the libusbx
mailing list