Re: [Libusb-devel] libusb-1.0 Windows backend when WinUSB isafilter driver

[Michael P. <mic...@gm...>]

Pete Batard wrote:
>> n 2010.08.22 01:40, Xiaofan Chen wrote:
>> > On Sun, Aug 22, 2010 at 8:36 AM, Xiaofan Chen<xia...@gm...>
wrote:
>> >> Actually you already have a different behavior between MS and MinGW
>> >> in the snapshots. The examples of MinGW are using the dynamic
>> >> linking. If you run them, you will get a application crash due to
missing
>> >> dll.
>> >
>> > Personally I think this might be better fixed. Simple thing is to copy
>> > the MinGW dll inside the MinGW examples.
>>
>> I don't think that's very logical. People don't expect to find a DLL in
>> examples.

Well, from the perspective of a sane layout, it's not logical, but I don't
know that "sane layout" is what we're after.  You've often stated you want
it to be incredibly easy for people to use.  Because of the search order of
the Windows loader, it makes sense that a dynamically-linked executable have
its DLL in the same directory if you want a lazy or careless person to be
able to double-click the executable and have it work.  Maybe even distribute
a 2-3 line .bat/.cmd file that passes the right command line arguments and
pauses before the console window closes, as long as we're cutting out the
build step for people who refuse to build it from source:

test-lsusb.bat:
  @echo off
  lsusb.exe
  pause

But the idea of being able to unzip and run in place is just a suggestion.
I don't particularly care what the binaries do.  And I'll add the caveat
that I'm basing this off the discussion, not having looked at the snapshot
layout yet.



>> I could have stopped with
>> providing only one set of samples (the static ones, because they're the
>> most straightforward to use, and less likely to cause issues), but since
>> both were available at no extra cost, I included both. If this becomes a
>> contention point, considering that there's no good reason to have 2 set
>> of samples really, I think I'll just drop the dynamically linked ones
>> and keep static.

Maybe keep it simple?  They are just examples, and, unlike the DLL/LIB/A/SO
files, are not likely to be redistributed as-is.  The source is more
important for the examples, though providing ONE working binary each is a
good idea.  If following one or both of Xiaofan's suggestions is infeasible,
maybe just include the static builds so we get fewer support requests on the
example snapshot?  Or document (if not already) how to use the snapshot on
the wiki somewhere?  But again, feel free to ignore my advice on this.


>> On the contrary, if I were to
>> place both the import and static library in the same dir, I very much
>> expect to see some complaints, which is why I'm not planning to do so.

Agreed.  They have the same name in MS compilers, don't they?



>> (I could rename it to "static lib" if needed).

Maybe "static" and "shared" as directory names?


Regards,
Michael