[PATCH 00/25] alsa-tools: efw-downloader: add initial version of firmwre downloader for Echo Audio Fireworks devices

[Takashi Sakamoto]

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