Hi, On Thu, Aug 27, 2020 at 02:57:04PM +0200, Takashi Iwai wrote: > On Thu, 27 Aug 2020 14:24:42 +0200, Takashi Sakamoto wrote: > > On Wed, Aug 26, 2020 at 01:31:53PM +0200, Takashi Iwai wrote: > > > Since it's based on meson build, it'll be tricky to include this in > > > alsa-tools whether others are all autoconf. The tarball creation is > > > done in the top directory and that assumes the execution of "make > > > alsa-dist" in each subdirectory. Without this integration, the > > > directory won't be included in the release. > > > > > > Could you work on it, too? > > > > I didn't have enough care of distributing the package. Thank you for the > > indication. > > > > Although it's possible to write configure.ac/Makefile.am for > > efw-downloader, I'd like to use meson.build for my convenience, especially > > for the convenience of gnome module[1] in meson (Nowadays software in GNOME > > project including GLib is mostly build by meson). > > > > As long as I know, the concept of release creation in GNU Autotools is > > different from the one in meson build system. GNU Autotools distributes > > scripts generated from Makefile.am/configure.ac and so. On the other > > hand, meson distributes files maintained by git or mercurial. > > > > If we have a space to make enough arrangement for alsa-tools, the > > top-level Makefile should be changed to have two variables for > > subdirectories which includes software built by GNU Autotools and the > > others, then be changed further for configure/install/alsa-dist/clean > > targets. > > > > Nevertheless, the idea to mix all of software built by several types of > > build system into one repository is not so convenient itself. I'll take > > more time to investigate further for better packaging of alsa-tools. > > (Tools like Android repo is a bit over-engineering in the case, mmm) > > > > I decline the patchset for now. > > OK. It's indeed awkward to mix up both auto-tools and meson. > So the more suitable option would be either to modernize everything > with meson, or just create a configure.ac for efw-downloader. > Maybe the latter is easier, as the dependency would be only about > hinawa and the check via pkgconfig is trivial even with automake. > But, obviously, modernization is more appealing (with a risk of > breakage, as always :) The modernization is itself preferrable, but the idea of everything with meson is not better since we have several build systems in the world. In my opinion, the preferrable way is to enable developers to add software without limitations about its build system and dependency. As a quick glance, below applications have dependency to Gtk+2 or Gtk+3. For them, replacement with meson build system is reasonable: * echomixer * envy24control * hdajackretask * rmedigicontrol As you know, Gtk+2 is already obsoleted, thus the above should be ported to Gtk4[1]. Qlo10k1 is only an application of Qt3. I guess CMake is more preferrable than GNU Autotools in the case. As well as Gtk+2, Gt3 is already obsoleted. Hwmixvolume is written by Python 3, thus it's better to follow the standard way in Python world (setup.py). For the other software, it doesn't matter still to use GNU autotools. However, ld10k1 includes tools (ld10k1/lo10k1/dl10k1) seem to depend on local library (liblo10k1) but Makefile seems not to describe the dependency appropriately. At present, I have no proposal for the issue, but it's possible to split the software into several repositories depending on build system, like: * alsa-tools-meson * alsa-tools-cmake * alsa-tools-python * alsa-tools-autotools Then put release script to alsa-tools repository with git-submodules for them. [1] Debian Bug report logs - #967250 alsa-tools: depends on deprecated GTK 2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967250 Regards Takashi Sakamoto
