Re: [Libusb-devel] >=autoconf-2.63 no grok multiline AC_CONFIG_FILES?

[Pete B. <pb...@gm...>]

On 2010.12.03 10:59, Xiaofan Chen wrote:
> What if you not using msys-git/TortoiseGit? For one I do not
> use them and I use Cygwin git. It works the same as git under
> Linux. In that case, maybe things would work better for you.

Please understand that we are not trying to address a problem that only 
affects me here, even if I'm the only one to have reported it so far. We 
are trying to address a problem that *will* potentially affect all 
TGit/msys-git users even if they switch to different gits afterwards, 
including Linux. As far as my testings are concerned, any user of 
Tgit/msys-git using default settings should be affected, and that's not 
something we can fix upstream.

Even if you later switch to using cygwin or even Linux git on the 
directory you cloned with Tgit/msys-git, you will get issues [1], so 
basically that means either not using Tgit/msys-git or making sure that 
you change your default options before you even attempt to clone a 
directory. If someone is new to git (yes, you can be both new to git AND 
want to participate in libusb internal development), they're unlikely to 
be aware of the problem. Sure, we could point the issue out on our 
website, but that's just a selfish approach IMO - see the end of my e-mail.

Even if I was the only person affected, "don't use tool X, use tool Y 
instead" seems like poor advice when we know exactly how to fix the 
issue for tool X, especially when it's a 10 secs fix. When something's 
difficult to fix with tool X, advocating switching to tool Y may be good 
advice. That is not the case here.

And I'm really starting to wonder how committed we are to our users when 
it looks like, there again, we are reluctant about introducing *simple* 
30 seconds fixes in our tree, and instead foster the "upgrade your tools 
/ don't use tool X" approach. We know exactly how to avoid the issue, 
and it's trivial to fix, so let's help our users instead of placing yet 
another set of demands on them dammit!

But let me elaborate a little bit on where I come from here.
Unless you are omniscient and know for certain that this fix will 
introduce problems that will result in more time spent by the libusb 
developers to fix them than the collective amount of time that is going 
to be wasted by libusb users having to switch/upgrade/fix their tools, 
then you should go for the fix, because the expectation is that, for 
what looks to me as a very selfish reason (spare some of *your* time by 
placing an unneeded burden on others), you are likely to deprive your 
users of the very same valuable resource, and more damagingly, to a 
greater collective amount, especially if you aim your project at 
becoming a de-facto standard of accessing USB devices on all the major 
platforms. That's the precise reason I pushed so hard for the CJK 
libtool fix, that's the reason I will push again to have xusb and MSVC 
projects included, regardless of what the maintainers want, as the 
equation is very simple:

If you know that implementing something will take some or potentially a 
lot of your development time, but you suspect that not doing it will 
force your users to collectively waste a larger amount of time, then it 
becomes *criminal* not to do it when you have the capacity to do so.

Not providing xusb (which we have the capacity for - it's already there) 
= time wasted for users who want something with more meat than lsusb. 
Not having MS project files (same) = time wasted for MS users that have 
either to recreate or download them for a separate source, etc. That's 
how libusb should work IMO and also why, for instance, we should also be 
fast-tracking things like hotplug (capacity wise, it's pretty much 
already there too!), because there is actual demand for it, and, unlike 
what is the case for libusb-win32, there doesn't exist an alternative, 
which results in time wasted (working around or doing their own 
implementation) by our users.

Regards,

/Pete

[1] 
http://pete-tech.blogspot.com/2010/12/that-darn-libtoolize-acconfigmacrodirm4.html