[haiku-gsoc] Re: [libusb] Libusb Port to Haiku OS
- From: Akshay Jaggi <akshay1994.leo@xxxxxxxxx>
- To: Pete Batard <pete@xxxxxxx>
- Date: Sat, 9 Aug 2014 20:00:50 +0530
Hi Pete,
An issue with the current setup is that even if somehow we are able to bypass
AC_PROG_CXX in autotools, then also, due to mention of C++ sources in
libusb/Makefile.am, make will use CXXLD to link. This happens even if no CPP
source was touched while compiling on that OS.
A way around this issue was suggested on the Haiku IRC channel. Using
AC_CONFIG_SUBDIRS
(http://www.gnu.org/software/automake/manual/html_node/Subpackages.html), and
making the haiku part of libusb into a subpackage with its own configure and
makefiles. (Thanks to PulkoMandy and mmu_man for this).
Using this approach we were able to separate out the CPP dependent part into
Haiku specific configure files.
I tested this configuration, with a dummy g++, overriding the default one, on
OS X. It builds perfectly fine and no CPP checks are initiated.
I have updated the pull request. Please review. :)
Thanks and Regards,
Akshay Jaggi
On 09-Aug-2014, at 4:26 am, Pete Batard <pete@xxxxxxx> wrote:
> As far as I'm concerned, the only contention point I see that needs to
> be addressed is to not force non-Haiku platforms to have a C++ compiler
> available.
>
> After that, I'd say it's up to the backend developer(s) to implement the
> platform specific parts in whichever way they think is best. For
> instance, I never really saw the Haiku specific C++ implementation from
> the proposal as that much of an issue.
>
> Of course, I would also tend to prefer if all the backends were
> implemented in the same language, for various reasons, but it's also
> well known that BeOS and derivatives have the particularity of having
> been implemented in C++ from the ground up. Thus, we probably want to
> keep realistic and leave the developer(s) of the proposal use the
> language they think is best suited to interact with their OS. Unless
> it's easy to come up with and maintain then, I'm not sure trying to
> force a C implementation of Haiku might be that productive (a bit in the
> vein of having to implement POSIX constructs such as a poll emulation on
> Windows - doable, but a PITA to get right and maintain and not a great
> use of resources if it can be avoided).
>
> Anyway, to come back to my views on the matter at hand:
>
> - As long as they are compartmentalized into their specific backends, I
> see no issue with having C++ files in the libusb source.
>
> - With regards to modifying bootstrap.sh to add/remove AC_PROG_CXX, I
> don't think that will fly. The issue here is that, if you look at the
> source tarballs we provide to our users, you'll find that they contain a
> fully generated configure, and we also remove bootstrap/autogen from
> these tarballs altogether. So whatever conditional detection needs to
> happen must also be able to occur in the generated configure. Besides,
> another concern from adding to bootstrap/autogen is if you're going to
> start to rely on external tools such as sed, etc., which not all
> platforms may have (eg. MinGW on Windows) and we come back to forcing
> people using a toolchain to install something they don't actually need,
> just to keep another platform happy...
>
> - I also saw that
> http://osdir.com/ml/bug-autoconf-gnu/2010-05/msg00001.html talk when I
> was trying to figure out if AC_PROG_CXX would really force everyone to
> have a C++ toolchain, and if the idea is to try to exploit the current
> (broken) behaviour of autotools, I'd strongly vote against it. We should
> expect such behaviour to be fixed at any time.
>
> All in all, I guess it all boils down to what you guys think might be
> simplest to achieve: work around the AC_PROG_CXX in autotools or switch
> the Haiku sources to C.
>
> Regards,
>
> /Pete
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> libusb-devel mailing list
> libusb-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
Other related posts:
