search

dyne / frei0r

A large collection of free and portable video plugins
https://frei0r.dyne.org/
GNU General Public License v2.0
419 stars 90 forks source link

consolidate build-systems #125

Closed umlaeute closed 1 year ago

umlaeute commented 2 years ago

as of #95 , i think it's clear that having to maintain two (complex) build-systems is a chore and error prone. iirc, there's hasn't been a release in almost 5 years that had a non-broken autotools setup.

i therefore suggest to just remove the build system you do not like.

jaromil commented 2 years ago

@umlaeute hi! yes there are glitches. but before removing, do we have an overview of distro packages and which build system they use?

umlaeute commented 2 years ago

i obviously don't have any such overview.

however, i have a data point: as the maintainer for the Debian packages, that universe (including Ubuntu, Mint, ...) is in my responsibility (i don't really know whether any of these distributions do their own packaging of frei0r; but i doubt it): i do prefer autotools, so that is what I use for packaging frei0r. But if a package uses Cmake instead of autotools, i use that instead. Or qmake, or whatever.

If a build-system is well maintained and uses standards, it's typically not a big deal. If there are issues, I can (and do) always report them, so they got fixed.

Currently, I have to invest time for each new frei0r release to fix the autotools build system. I haven't switched so far, because I'm lazy; but the current situtation does already have a cost for distro packages.

jaromil commented 2 years ago

BTW many thanks for maintaining frei0r in debian!!

in lack of an impact assessment I am wary of removing autoconf, but I am happy to read you have no problems switching to cmake, please do so if that makes you more comfortable, most people seem to already prefer that.

the autotools setup on release 1.8.0 has a change and a bug:

  1. we changed the way we ship tarballs since the configure script is not already generated
  2. I left a bug by deleting an obsolete TODO file, which is fixed in the latest commit ee21d09
ddennedy commented 2 years ago

In my opinion no impact assessment is needed or warranted especially because CMake is not something obscure. As if the Linux ecosystem is not fragmented enough what about all the different BSD, macOS, and Windows systems? So what if downstream consumers of a project need to change a little to adapt? It happens all of the time any time you make a change: version numbers change, dependencies can change, interfaces change, deprecations are removed, bugs get introduced, etc. Last year MLT switched to CMake. We did not do an impact study or get any complaints. This goes back to #95. I do not volunteer to fix that, do you? But I am willing to help by removing the autotools build system.

SonnyWalkman commented 1 year ago

Maybe consolidate to meson and ninja like gstreamer has gone to? frei0r has plugins in the gstreamer-bad-plugins repo.

jaromil commented 1 year ago

Considering #114 I believe the way to consolidate is to keep cmake and perhaps just that, as also @umlaeute proposed and @ddennedy agreed.

jaromil commented 1 year ago

Proceeding on this in #130 while setting up a release pipeline based on cmake.

jaromil commented 1 year ago

This is now done as soon as I'll merge #142 and tag 2.0 release, an announcement will follow.

If we like to stay in touch more regularly we have an on-topic channel on https://t.me/frei0r