On Dec 24, 2009, at 2:09 PM, Arjen de Korte wrote:
However, it doesn't include the libusb-config binary.
That sucks... :-(
But the gist of it is that they just hardcode "" and "-lusb" for
$CFLAGS and $LDFLAGS, respectively.
Ditto... :-(
For many FreeBSD 8.0 users, this will be a non-issue, since they can
just run 'make install' in the ports directory. However, given all of
the USB stack changes, I suspect we might have to ask some users to
test against a SVN version of NUT, so it might be nice to enable USB
support out-of-the-box.
Suggestions?
Well, the only thing we could do, is fallback to these defaults if
the detection via 'libusb-config' fails to detect the libusb presence.
Just saw that patch. Should we check for "usb.h" (the 0.1 API) instead
of "libusb.h"? Also, should we verify that some of the functions like
"usb_init()" are usable?
But I really feel that this is a regression in FreeBSD and that not
including libusb-config is really hurting. I fail to understand why
the FreeBSD maintainers choose this is easier to fix in all packages
that use libusb, than to just include a 'libusb-config' that simply
returns these values.
Agreed that it is a regression. I even checked for a pkg-config file,
but didn't see one in the usual places.
I could file a bug. Haven't done that with FreeBSD before, but it
seems like a simple thing for them to add.
Arjen: if you don't have much free time, I can do some local testing
here, but I am not sure which of the autoconf library search routines
I should use as a model.
I've submitted something. Once you get the hang of it, the autoconf
tools are remarkably easy to use.
Yeah, I am no stranger to m4 and all of the other technologies under
the hood, but finding the "right" way to do something in autoconf is
often tedious, and not always obvious.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev