Nice-to-have fix for autogen.sh

[Pete Batard]

On 2012.02.01 15:45, Segher Boessenkool wrote:
>>>> o autogen.sh is only used by maintainers - official distributions
>>>> would have a configure (and Makefile) ready to use, so no need for
>>>> autogen.
>>>
>>> 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!

Again, it's not a matter of annoyances. It's a matter of logic and 
trying to provide the libusbx option that will benefit the more people 
the most.

If someone builds an hospital in front of your house, it may block the 
sun and you may be annoyed by it, but the overall benefits are expected 
to massively outweigh your inconvenience.

Therefore, let me reframe the logical reasons I see for keeping out 
autogen as it is, in terms of what will benefit our users most.

Once we start having regular releases, people picking up the source from 
git will want the latest bells and whistle, and will have at least some 
expectations that things may not be as stable with libusbx/git as they 
would be with libusbx/release.

Thus, because their probability of running into a pure libusbx issue is 
much higher than with a release, I see it as logical to want logging on 
by default there.
This is even more true as if logging is off, you don't even get minimal 
error messages from libusbx, just error codes, and at least some users 
don't seem to find them too descriptive. Not having logging would place 
an unnecessary hurdle on people who might be getting started with 
libusbx and would otherwise get some hints as to why their libusbx based 
app may not work as they expect. The easier we make it to get started 
with libusbx and figure out how to use it, the better.

Thus, having logging on by default for git users is IMO a logical must 
have, and the only possibility we have to do that is through autogen. 
Else we have to rely on users who are not familiar with our configure 
options to run configure --help, figure out what we use, and enable it 
themselves. If our goal is to help git users of libusbx, I don't think 
that flies.

In the same vein, having samples built by default is probably also a 
must have for anybody getting started with a new project, as they might 
then be able to play with it immediately. On the other hand, this could 
(and probably should) be turned on by default in configure.ac, as it 
doesn't really impact release users, especially as we have very few 
samples to build.


>> I strongly believe that the default for any developers who wants to
>> contribute to libusbx should be to have logging.
>
> Why only for developers though?
>
> Run-time configurable logging sure would help :-)

Not sure I understand your point there, since I went the extra mile to 
provide just that for all the people who use either my binaries or code 
from my branch, and as I stated, once we have the feature in in 
official, the importance of having logging on by default in autogen is 
greatly reduced.

>>> If you're building a lot, you probably should run some ./build
>>> anyway ;-)
>>
>> Why should I, when the default autogen.sh is just fine?
>
> Most people at least want a --prefix if they build a lot (since
> they typically have many versions installed).

Which they can provide to autogen.sh. This is not even a option they 
need to check from configure --help (unlike logging) as it's expected to 
be the same everywhere.

>>> Let's go with the principle of least surprise, so do what most
>>> projects do (or the most authoritative ones).
>>
>> Let's go with the principle of what will be most helpful for our users.
>
> That is the same thing, in general.

Well, considering that there are quite a few projects that seem to run 
configure from autogen, I'm not sure we can assert that the expectation 
is not to have it there, or that it will surprise users if it is. Plus, 
I think it's better do what we logically think will benefit the most 
people, than what will least surprise them.

This being said, if we can't come up with an option that everybody is 
happy with with regards to autogen, we might as well include 2 scripts 
and move on. It isn't exactly something that pertains to releases in the 
first place...

Regards,

/Pete