2012/10/31 Sean McBride s...@rogue-research.com:
On Wed, 31 Oct 2012 20:07:17 +0100, Ludovic Rousseau said:
You missed my latest change about build for 32 and 64 bits :-(
I propose to add to Xcode/common.xcconfig:
ARCHS = $(ARCHS_STANDARD_32_64_BIT)
Or maybe there is a better place for this
On Thu, Nov 1, 2012 at 4:19 PM, Ludovic Rousseau
ludovic.rouss...@gmail.com wrote:
I mostly agree. But: :-)
- the default is then to build a 32-bits library on my 64-bits system.
I don't know why.
- Xiaofan complained that only one architecture was targeted.
To me under Lion and Mountain
2012/11/1 Xiaofan Chen xiaof...@gmail.com:
On Thu, Nov 1, 2012 at 4:19 PM, Ludovic Rousseau
ludovic.rouss...@gmail.com wrote:
I mostly agree. But: :-)
- the default is then to build a 32-bits library on my 64-bits system.
I don't know why.
- Xiaofan complained that only one architecture was
On Thu, 1 Nov 2012 09:19:38 +0100, Ludovic Rousseau said:
I mostly agree. But: :-)
- the default is then to build a 32-bits library on my 64-bits system.
I don't know why.
- ??Xiaofan complained that only one architecture was targeted.
The current configure script also builds for only one
2012/10/31 Xiaofan Chen xiaof...@gmail.com:
On Wed, Oct 31, 2012 at 12:55 AM, Ludovic Rousseau
ludovic.rouss...@gmail.com wrote:
It is not (or no more) specific to Mountain Lion.
I just tried the github code on Snow Leopard using Xcode 4.2 and it
builds without problem.
Please resynch the
On Wed, Oct 31, 2012 at 4:25 PM, Ludovic Rousseau
ludovic.rouss...@gmail.com wrote:
2012/10/31 Xiaofan Chen xiaof...@gmail.com:
Still there is a problem now that I only see 32bit target now,
the valid architecture says i386 and x86_64 but I only
see 32bit target now.
This is because I used
Hi,
I took Ludovic's Xcode branch and merged it into my own branch, then did some
more work:
https://github.com/seanm/libusbx
Notably, I added .xcconfig files as I mentioned... IMHO, this is preferable to
setting the project/target settings in the project's GUI, because it's hard to
diff and
2012/10/31 Sean McBride s...@rogue-research.com:
Hi,
I took Ludovic's Xcode branch and merged it into my own branch, then did some
more work:
https://github.com/seanm/libusbx
Notably, I added .xcconfig files as I mentioned... IMHO, this is preferable
to setting the project/target
On Wed, 31 Oct 2012 20:07:17 +0100, Ludovic Rousseau said:
You missed my latest change about build for 32 and 64 bits :-(
I propose to add to Xcode/common.xcconfig:
ARCHS = $(ARCHS_STANDARD_32_64_BIT)
Or maybe there is a better place for this setting.
Actually, I didn't miss it; it's just that
2012/10/30 Xiaofan Chen xiaof...@gmail.com:
On Tue, Oct 30, 2012 at 8:03 AM, Sean McBride s...@rogue-research.com wrote:
On Mon, 29 Oct 2012 23:57:26 +, Pete Batard said:
Regarding build using Xcode I added a config.h for Xcode. So it is now
possible to build using Xcode without using
On 2012.10.26 09:18, Ludovic Rousseau wrote:
Regarding build using Xcode I added a config.h for Xcode. So it is now
possible to build using Xcode without using ./configure first.
Use my xcode branch at https://github.com/LudovicRousseau/libusbx/tree/xcode
I haven't had a chance to follow
On Mon, 29 Oct 2012 23:57:26 +, Pete Batard said:
Regarding build using Xcode I added a config.h for Xcode. So it is now
possible to build using Xcode without using ./configure first.
Use my xcode branch at https://github.com/LudovicRousseau/libusbx/tree/xcode
I haven't had a chance to
On Tue, Oct 30, 2012 at 8:03 AM, Sean McBride s...@rogue-research.com wrote:
On Mon, 29 Oct 2012 23:57:26 +, Pete Batard said:
Regarding build using Xcode I added a config.h for Xcode. So it is now
possible to build using Xcode without using ./configure first.
Use my xcode branch at
Am 13.10.2012 03:03, schrieb Xiaofan Chen:
On Sat, Oct 13, 2012 at 2:15 AM, Orin Eman orin.e...@gmail.com wrote:
Personally, I think it's better to supply native build methods than to try
to force autotools to work on systems that don't support it.
Me too. So autotools for Linux and BSDs,
On Mon, Oct 29, 2012 at 1:00 AM, Sven Köhler sven.koeh...@gmail.com wrote:
Am 13.10.2012 03:03, schrieb Xiaofan Chen:
On Sat, Oct 13, 2012 at 2:15 AM, Orin Eman orin.e...@gmail.com wrote:
Personally, I think it's better to supply native build methods than to try
to force autotools to work on
2012/10/25 Sean McBride s...@rogue-research.com:
On Fri, 12 Oct 2012 23:40:46 +0200, Ludovic Rousseau said:
To make Xcode happy I had to use #include libusb.h instead of
#include libusb.h for local headers.
As I said, I had to do the same. Now, for my own development testing, I'm
now
On Fri, 12 Oct 2012 23:40:46 +0200, Ludovic Rousseau said:
To make Xcode happy I had to use #include libusb.h instead of
#include libusb.h for local headers.
As I said, I had to do the same. Now, for my own development testing, I'm
now trying something else... instead of building a libusbx
On Wed, Oct 17, 2012 at 1:46 AM, Ludovic Rousseau
ludovic.rouss...@gmail.com wrote:
2012/10/16 Sean McBride s...@rogue-research.com:
On Tue, 16 Oct 2012 07:41:43 +0800, Xiaofan Chen said:
Thanks. A few more issues. I do not quite understand 1),
I think 2) is not a real issue. 3) may need to be
2012/10/16 Pete Batard p...@akeo.ie:
On 15 October 2012 14:04, Sean McBride s...@rogue-research.com wrote:
I see logging the 'long' as an advantage,
Could we please avoid using a what-frigging-size-is-this? long and
use an int##_t instead?
We can't do that.
poll(3) is defined as
int
On Tue, 16 Oct 2012 07:41:43 +0800, Xiaofan Chen said:
Thanks. A few more issues. I do not quite understand 1),
I think 2) is not a real issue. 3) may need to be fixed.
1) Logic error
/Users/xiaofanc/work/libusbx/ludovic/libusbx/libusb/descriptor.c:561:8:
Function call argument is an
On Sat, 13 Oct 2012 20:35:24 +0200, Ludovic Rousseau said:
/Users/xiaofanc/work/libusbx/ludovic/libusbx/libusb/io.c:1877:35:
Implicit conversion loses integer precision: 'long' to 'int'
timeout_ms = (tv-tv_sec * 1000) + (tv-tv_usec / 1000);
It is fixed in
2012/10/15 Sean McBride s...@rogue-research.com:
On Sat, 13 Oct 2012 20:35:24 +0200, Ludovic Rousseau said:
/Users/xiaofanc/work/libusbx/ludovic/libusbx/libusb/io.c:1877:35:
Implicit conversion loses integer precision: 'long' to 'int'
timeout_ms = (tv-tv_sec * 1000) + (tv-tv_usec /
On Mon, 15 Oct 2012 18:52:18 +0200, Ludovic Rousseau said:
I don't know why your code would be better. Maybe it is but you should
explain.
One problem with your code is that the value used for the debug may
not be the value really used if an integer overflow occurs.
You log timeout_ms but the
On 15 October 2012 14:04, Sean McBride s...@rogue-research.com wrote:
I see logging the 'long' as an advantage,
Could we please avoid using a what-frigging-size-is-this? long and
use an int##_t instead?
Regards,
/Pete
On 2012.10.12 23:11, Pete Batard wrote:
On 2012.10.12 22:40, Ludovic Rousseau wrote:
Maybe this commit [2] can go upstream.
[2]
https://github.com/LudovicRousseau/libusbx/commit/f8dac33a71a7b056b5186e11cee2aa12f3539be6
Pushed.
Regards,
/Pete
On Mon, 1 Oct 2012 22:01:39 +0100, Pete Batard said:
Now, if a dependency on CMake is preferable, I'm not closing the door on
either (After all, I did add Vitali's CMake support in my branch when he
proposed it), but I'd like to hear what others have to say.
I just forked libusbx on github and
Sean McBride wrote:
I just forked libusbx on github and tried to build it. README.git
says run either ./autogen.sh or ./bootstrap.sh but both result in:
libtoolize or glibtoolize was not found! Please install libtool.
autotools used to be part of Xcode, but was removed as of 4.3 (March
On Fri, 12 Oct 2012 20:46:45 +0200, Ludovic Rousseau said:
autotools used to be part of Xcode, but was removed as of 4.3 (March 2012).
You can install the autotools from another Apple package named
Command Line Tools.
See http://apple.stackexchange.com/questions/40759/missing-autoconf-
On Fri, 12 Oct 2012 19:03:30 +0200, Peter Stuge said:
Other than finding and installing 'libtoolize', is there another way
to build?
I guess not. Feel free to contribute something.
Where can I find Vitali's CMake support? I'd be interested to know what state
it's in...
Cheers,
--
Sean McBride wrote:
Note that autotools are requited _only_ for people using the GIT
version.
What is the difference? What is included with the released
version that is not included with git, and why?
The difference in this case is that the autotools have been run by
whoever created the
Sean McBride wrote:
Other than finding and installing 'libtoolize', is there another
way to build?
I guess not. Feel free to contribute something.
Where can I find Vitali's CMake support? I'd be interested to know
what state it's in...
On 2012.10.12 20:10, Peter Stuge wrote:
Sean McBride wrote:
Where can I find Vitali's CMake support? I'd be interested to know
what state it's in...
https://github.com/vlovich/libusb/tree/cmake-support
It's also in my branch. This is the one feature I didn't import into
libusbx when I
Sean McBride wrote:
Homebrew [1] is a very nice tools for installing external tools on
Mac OS X.
$ brew install libtool
On Mac at least, that's now 3 dependencies:
- install Xcode
- install homebrew
- 'brew install' libtool
vs
- install Xcode
- install CMake
vs what is
On Fri, 12 Oct 2012 23:40:46 +0200, Ludovic Rousseau said:
I provide an Xcode project in my xcode branch at [1]. It was easy to
setup (on Mountain Lion).
Yes, I created my own too. Easy to setup, as you say. But not so easy to
*maintain*. If a non-Mac user adds/removes a file, he cannot
On 2012.10.12 22:40, Ludovic Rousseau wrote:
Maybe this commit [2] can go upstream.
[2]
https://github.com/LudovicRousseau/libusbx/commit/f8dac33a71a7b056b5186e11cee2aa12f3539be6
I don't have any objection. Anyone sees an issue?
Regards,
/Pete
35 matches
Mail list logo
