No more -binaries.7z release?

[rom1v]

Hi

For libusb 1.0.26, you provided libusb-1.0.26-binaries.7z. It was very convenient, there was already the pkgconfig file, with the correct directory hierarchy ready to add libusb as a dependency in meson for cross-compiling.

I use it in my release script so that libusb is available in meson.

There is no such release in libusb 1.0.27. Any particular reason?

[mcuee]

The file is there, the name is libusb-1.0.27.7z, which is in line with previous release like 1.0.25 or earlier.
https://github.com/libusb/libusb/releases

[rom1v]

The file is there, the name is libusb-1.0.27.7z

Nope, this is not the same structure in the archive.

in 1.0.26, there was both:

• libusb-1.0.26-binaries.7z
• libusb-1.0.26.7z

[mcuee]

We do not want to use the structures of libusb-1.0.26-binaries.7z any more.

[mcuee]

In any case, the Windows binaries are provided as is. You can always re-organize whichever way you like.

[rom1v]

Oh, ok. I'm disappointed, it had directly the expected structure and a pkgconfig file.

[mcuee]

Reference for previous discussions.

• Reminder: Return Windows r1.0.27 distributions [and later] to Traditional Packaging Structure as used in r1.0.25 and below.  #1166

[mcuee]

I guess different people have different preferences of Windows binary package structures.

@tormodvolden

Just wondering if you have any comments here. Thanks.

[rom1v]

For illustration, here is the script I adapted to recreate the expected directory structure and the pkgconfig file for the 1.0.27 release: https://github.com/Genymobile/scrcpy/commit/upgrade_libusb_1_0_27/

[tormodvolden]

"Expected"? Different people "expect" different things. Cannot please them all. It caused an uproar when we shipped the new structure in libusb-1.0.26-binaries.7z so we uploaded a libusb-1.0.26.7z afterwards.

Actually if you have a working MinGW setup, you are attacking this is in the wrong end. You shouldn't need to deal with binaries. Just unpack the source release, run ./configure --prefix "$(WIN64_BUILD_DIR)/local" && make install and you will get the pkgconfig files and libraries where they should be.

[tormodvolden]

Thanks for maintaining scrcpy BTW, very nice software.

[rom1v]

@tormodvolden Thank you for your answer.

"Expected"? Different people "expect" different things.

Sorry for not being clear, here "expected" meant "expected for my project" (the directory structure my project expects), not in general.

Actually if you have a working MinGW setup, you are attacking this is in the wrong end. You shouldn't need to deal with binaries.

Yes, I could build all the dependencies directly during the release. For now, I do differently (even for libs that I cross-build manually like ffmpeg, I publish the binaries (here) and the scrcpy release script just retrieves it). One benefit is that people can cross-build scrcpy for Windows without building all the dependencies themselves, but I agree it is not necessarily the best solution. I might do differently in the future (refs Genymobile/scrcpy#4490 but I always procrastinate when it is about build systems and CI 🙃)

[tormodvolden]

I cannot comment on your other dependencies, but the libusb build is very small and quick, and has very few build dependencies (make, a shell and a compiler?) thanks to the included configure script which does all the magic.

[mcuee]

BTW, I was thinking of mentioning MSYS2 mingw binary distribution. But then I remember that MSYS2 has removed 32bit mingw32/clang32 binaries for quite some packages, including libusb, libusb-compat-0.1 and libftdi.

MSYS2 now only provide binaries for clang64, clangarm64, mingw64, ucrt64
https://packages.msys2.org/base/mingw-w64-libusb
https://packages.msys2.org/base/mingw-w64-libusb-compat-git
https://packages.msys2.org/base/mingw-w64-libftdi

Interestingly they still provide 32 binaries for hidapi.
https://packages.msys2.org/base/mingw-w64-hidapi

[rom1v]

@tormodvolden Thank you, you gave me the motivation to finally work on that tonight 👍

My release script now cross-builds all the dependencies from sources for Windows 32-bit and 64-bit: Genymobile/scrcpy#4713 🎉

[tormodvolden]

I looked at your libusb.sh. You are actually not downloading the official release tarball (.bz2) but an artifact that GitHub generates against our wishes (.gz). The official tarball contains the configure script, and "bootstrap.sh" is thus not necessary.

[rom1v]

Thank you for your review 👍 I changed to use the .tar.bz2.

Why do you release a source different from the git repo (equivalent to the .tar.gz)?

Here is the file difference:

diff

$ diff -U3 <(cd libusb-clone; tree) <(cd libusb-bz2; tree)

--- /dev/fd/63	2024-03-02 13:26:21.612080700 +0100
+++ /dev/fd/62	2024-03-02 13:26:21.616080749 +0100
@@ -2,14 +2,13 @@
 ├── AUTHORS
 ├── COPYING
 ├── ChangeLog
-├── HACKING
+├── INSTALL
 ├── INSTALL_WIN.txt
 ├── Makefile.am
+├── Makefile.in
 ├── NEWS
 ├── PORTING
 ├── README
-├── README.git
-├── README.md -> README
 ├── TODO
 ├── Xcode
 │   ├── common.xcconfig
@@ -21,6 +20,7 @@
 │   ├── libusb_debug.xcconfig
 │   ├── libusb_release.xcconfig
 │   └── release.xcconfig
+├── aclocal.m4
 ├── android
 │   ├── README
 │   ├── config.h
@@ -33,16 +33,20 @@
 │       ├── examples.mk
 │       ├── libusb.mk
 │       └── tests.mk
-├── appveyor.yml
-├── autogen.sh
-├── bootstrap.sh
+├── compile
+├── config.guess
+├── config.h.in
+├── config.sub
+├── configure
 ├── configure.ac
+├── depcomp
 ├── doc
 │   ├── Makefile.in
 │   ├── doxygen.cfg.in
 │   └── libusb.png
 ├── examples
 │   ├── Makefile.am
+│   ├── Makefile.in
 │   ├── dpfp.c
 │   ├── ezusb.c
 │   ├── ezusb.h
@@ -52,9 +56,11 @@
 │   ├── sam3u_benchmark.c
 │   ├── testlibusb.c
 │   └── xusb.c
+├── install-sh
 ├── libusb
 │   ├── Makefile.am
 │   ├── Makefile.am.extra
+│   ├── Makefile.in
 │   ├── core.c
 │   ├── descriptor.c
 │   ├── hotplug.c
@@ -100,6 +106,14 @@
 │   ├── version.h
 │   └── version_nano.h
 ├── libusb-1.0.pc.in
+├── ltmain.sh
+├── m4
+│   ├── libtool.m4
+│   ├── ltoptions.m4
+│   ├── ltsugar.m4
+│   ├── ltversion.m4
+│   └── lt~obsolete.m4
+├── missing
 ├── msvc
 │   ├── Base.props
 │   ├── Configuration.Application.props
@@ -129,8 +143,10 @@
 │   ├── stress_mt.vcxproj
 │   ├── testlibusb.vcxproj
 │   └── xusb.vcxproj
+├── test-driver
 └── tests
     ├── Makefile.am
+    ├── Makefile.in
     ├── init_context.c
     ├── libusb_testlib.h
     ├── macos.c
@@ -138,10 +154,6 @@
     ├── stress.c
     ├── stress_mt.c
     ├── testlib.c
-    ├── umockdev.c
-    └── webusb-test-shim
-        ├── index.js
-        ├── package-lock.json
-        └── package.json
+    └── umockdev.c
 
-14 directories, 131 files

[mcuee]

Thank you for your review 👍 I changed to use the .tar.bz2.

Why do you release a source different from the git repo (equivalent to the .tar.gz)?

https://github.com/libusb/libusb/releases/tag/v1.0.27

Note:
*.tar.bz are our official release files, these are proper release tarballs including configure.

*.tar.gz and .zip are something GitHub generates, unfortunately we haven't found a way to disable them. They are just a git snapshot, without e.g. configure.

*) https://github.com/orgs/community/discussions/6003