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