[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:39:34 +0200
On 08/08/2014 12:26, François Revol wrote:
> 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
>
Some workarounds:
http://stackoverflow.com/questions/20741878/disabling-cxx-support-for-libtool-after-calling-ac-prog-cxx
François.
>>>> 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:
