This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] libusb1.0 1.0.5


Hello,

Corinna wrote:
> The include dir is called /usr/include/libusb-1.0, the import libs are
> called /usr/lib/libusb-1.0.*.
> 
> That looks like a Cygwin-only naming convention.

No, that is what upstream uses, my packaging script is mostly a
./configure && make && make install.

> How are these dir and files named on Debian?

The same as above.

> For obvious reasons, the Cygwin files should allow to build against this
> libusb the same way as on Linux.

Sure, that is why the choice of not changing the upstream names.

> So, if the include dir is called
> usr/include/libusb, so they should on Cygwin.  Analog for the libs.
> Especially for the libs, it seems the filenames will clash with the old
> libusb.dll.a.

That is precisely why upstream decided to not call it just libusb, to
avoid the clash and permit both libraries to be installed at the same
time.

> Therefore I think what we need is a new libusb-win32 package, which
> consists only of the files necessary to install, run, and deinstall the
> package, but not the files to build against it.

That would break the compilation of all applications using the old
libusb API, the current brltty version for instance (the future version
can make use of libusb-1.0, that is why I'm packaging it).

> Then the new package
> can become a drop-in replacement development-wise and nobody
> accidentally develops against the old package.

That can not work. libusb-1.0 is a complete rewrite of the API.

> Does that make sense?

It seems you have missed the âwith an incompatible interfaceâ
part. Upstream really changed everything, making it a completely new,
independent library that has nothing to do with the original libusb
except the general goal. Actually, the brltty package can even build
against both and let the user choose between both at runtime, which is
particularly interesting since the original libusb works by using its
own hackish USB filter or driver, while libusb-1.0 uses the WinUSB API
(and there is no upstream plan to make one also use the approach of the
other).

> Btw., is the libusb-compat-0.1 layer part of this package?

It is not part of the usptream source and it not packaged in Debian,
that is why I have not packaged it.  It could be packaged separately, if
someone wants it.

Samuel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]