Yes, that is pretty terrible :-(
On Fri, Nov 9, 2012 at 3:42 PM, Xiaofan Chen wrote:
> On Sat, Nov 10, 2012 at 3:40 AM, Ted Middleton
> wrote:
> > Is this a known issue? I know that on Windows, this sort of promiscuous
> > interface claiming is apparently quite difficult - I've heard that the
You could still tell Xcode how much farther back you want to be able to
build for. I think that is reasonable. You could also argue that this only
matters if someone does a build to be redistributed in binary form and then
they should decide which OS releases they want their binary to work on.
On
Let me add a vote for properties such as location IDs as identified by the
OS. I can se how a general mechanism to retrieve properties would be good.
I actually think it would be fine to rely on the OS headers for properties
names if possible. After all if you are looking for an OS specific proper
Yes I read autogen.sh since I posted and saw what to does.
Sure, an INSTALL.git or even a README.git would be perfect (and a good
place to mention bootstrap vs autogen).
On Mon, Jul 23, 2012 at 1:39 PM, Pete Batard wrote:
> On 2012.07.23 12:23, Yves Arrouye wrote:
> > Maybe
>
> libusb has always had the autogen.sh script which generates (and runs)
> configure in a git tree. It works also with Mac OS X Xcode tools.
>
Okay. I personally do not build in the source tree (that tree is shared between
my Mac environment and a Linux VM; I have also taken this habit as it
Hi,
I was a bit surprised that the default installation obtained by cloning
(using git clone on the command line)
git://github.com/libusbx/libusbx.gitdid not include a configure or any
of the artifacts generated by the
autoconf suite.
Using a fresh cloned directory and having MacPort's autoconf a
Sorry for the slight thread hijack, but how/when do patches make it
into GIT, so we can just pull from GIT?
On Fri, May 25, 2012 at 10:16 PM, Xiaofan Chen wrote:
> On Thu, May 24, 2012 at 11:39 PM, Pete Batard wrote:
>> This one should work a bit better.
>>
>
> Let me try to use this as an exerc
On Fri, May 25, 2012 at 6:00 AM, Ludovic Rousseau
wrote:
> 2012/5/25 Pete Batard :
>> On 2012.05.25 13:22, Ludovic Rousseau wrote:
> I am fine with that.
> But that will not solve my problem.
>
> I need a way to tell libusbx to use stdout (for every logs).
>
> Bye
If all logs go to stderr, can't
I vote for stderr always too.
On Fri, May 25, 2012 at 5:39 AM, Pete Batard wrote:
> On 2012.05.25 13:22, Ludovic Rousseau wrote:
>> The problem is when the flows are redirected to a file. The outputs
>> are buffered and no more ordered correctly between stdout and stderr.
>
> Aha. I think I saw h
I am porting iguanaWorks' code to drive their USB IR transceiver to OS
X. Their code uses libusb(x). I am testing both on my Macbook and on
Ubuntu Linux inside Virtual Box. On Ubuntu Linux, a
But on OS X, if I set debug level to 3, I get an incessant stream of
timeout messages. I wonder: timeouts
>> and also am not sure what would then happen to the *.la etc. files
>> that only knew about one arch.
>
> They are libtool files which do not really matter except when using
> libtool to link against the library.
What I meant is that if I make install twice, only one arch goes into
the libtool f
.
YA
On Thu, May 24, 2012 at 4:39 PM, Sean McBride wrote:
> On Thu, 24 May 2012 15:24:10 -0700, Yves Arrouye said:
>
>>How can I do that? Just trying to pass arch flags in CFLAGS/LDFLAGS is
>>not working:
>
> Apple's Technical Note TN2137 describes how to get uni
How can I do that? Just trying to pass arch flags in CFLAGS/LDFLAGS is
not working:
% make
make all-recursive
Making all in libusb
CC libusb_1_0_la-core.lo
llvm-gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags
It does not help that the full command-line
Thanks for your long response, Peter.
> > It would be great if libusbx offered a uint32_t
> > get_usb_location_id(libusb_device *dev) [...]
>
> Well, unless we use the hash, which is something we could factorize as a
> common unique device ID across all backends (and which we may very well
> have
in a given port through that addressing
scheme).
YA
On Tue, May 22, 2012 at 4:06 PM, Peter Stuge wrote:
> Hi Yves,
>
> Yves Arrouye wrote:
> > It seems to me that location ID is worth being part of the topology
> > information, and offers a reliable way to identify a device on bo
Hi,
I stumbled upon libusbx when researching whether libusb would support
exposing the concept of a USB Location ID (which I am not sure is part of a
standard, but seems to be widely understood as available on Darwin/OS X and
Windows, and may be available or constructed on Linux). It seems that th
16 matches
Mail list logo
