[haiku-gsoc] Re: [libusb] Libusb Port to Haiku OS
- From: François Revol <revol@xxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Fri, 08 Aug 2014 12:26:40 +0200
On 08/08/2014 10:58, pulkomandy wrote:
> On Fri, Aug 08, 2014 at 10:29:46AM +0200, Ludovic Rousseau wrote:
>> Hello,
>>
>> 2014-08-08 10:08 GMT+02:00 Akshay Jaggi <akshay1994.leo@xxxxxxxxx>:
>> But LT_INIT runs a few tests, if AC_PROG_CXX is defined. And the configure
>> fails.
What's the error actually?
Could they have been fixed in upstream auto*/libtool?
It seems there is also LT_LANG() that is equivalent (but maybe not
identical):
http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html
>>> A way I see through this, is add a check in bootstrap.sh, and if
>>> we detect that the system is Haiku, add the corresponding lines
>>> (the cpp
>>> sources one, and AC_PROG_CXX) to configure.ac and Makefile.am.
>>> This seems better than playing with Makefile and Configure
>>> scripts, making them all the more complicated.
>>> I would like to know your views on this.
>>
>> Another option is to write the Haiky backend in C instead of C++.
I guess moving the AC_PROG_CXX inside the *-haiku* case probably won't
work either.
Possibly adding CXX=g++ in the haiku case and defining .cpp.o and
COMPILE.c++ make rules might work...
Btw, LT_INIT was mentionned but it seems not called, only AC_INIT.
Shouldn't it be called explicitly at some point?
Oddly enough, adding just AC_PROG_CXX under AC_PROG_CC and doing:
CXX=g-- ./configure
just works, configure doesn't even complain...
Anyway this looks more like a bug in libtool/autofools that should be
fixed rather than worked around, at least on the long term.
It might also be the occasion to fix all the existing warnings, like:
examples/Makefile.am:1: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
libusb/Makefile.am:3: warning: source file 'os/linux_usbfs.c' is in a
subdirectory,
libusb/Makefile.am:3: but option 'subdir-objects' is disabled
Unless some people rely on antique versions for embedded?
(I won't tell them "just fix your OS/SDK" because that's what people
have been constantly yelling at me when I upstreamed patches for BeOS
and Haiku... and its very unpleasant)
>> I had a rapid look at your code and see no strong reason to use C++
>> instead of C. But I may have missing something.
>> How do you justify the use of C++?
>
> Hello,
>
> The code uses Haiku APIs which are only available in C++ (defined in our
> USBKit.h header). Even if the backend itself was converted mostly to C,
> it would require subclassing BUSBRoster to listen for USB devices being
> plugged and unplugged. We are not really willing to modify Haiku to add
> an equivalent C API specifically for libusb.
While BeOS had file system notifications way before inotify ever existed
("BeOS did it 20 years ago"®), it is only exposed as a C++ interface,
which is what BUSBRoster uses.
And it's not easy to use it from C, even if you hooked a listening
thread directly you would have to decode the flattened BMessage data in
plain C as well.
I meant to try to add some inotify-like calls long ago but that's not
going to happen any time soon anyway.
François.
Other related posts:
