flac dev - May 2022 - Build systems to keep

On 5/1/22 19:22, Martijn van Beurden wrote:
> Hi all,
> 
> Currently flac has 4 build systems: autotools (configure.ac), CMake,
> Makefile.lite and Visual Studio files. I think this is too much and
> like some opinions on which to remove.
> 
> I propose to remove the Visual Studio files (a mention has already
> been put in the changelog and README of the 1.3.4 release that they
> will be removed) because that was already planned. CMake takes over
> the role of providing a build system for Visual Studio. As recent
> releases of Visual Studio actually feature integration of CMake, one
> could see CMake as being 'endorsed' by Microsoft. Visual Studio
users
> will get a better maintained and configurable build system instead of
> the rigid files flac provides right now.
> 
> I'd also like to remove the Makefile.lite build system. From a remark
> in the README it seems it was at some point created to provide an
> alternative or back-up for the autotools build system, but a much more
> flexible alternative is now available: CMake.
> 
> I'd like to hear your thoughts on this matter.
Thanks for your work taking care of flac.

I think a build system proliferation as FOSS is used on more platforms 
than expected is a bit of a rite of passage for projects started longer 
than 10 years ago.  Libwebsockets grew in a similar way, make, replaced 
by autotools, then msvc project files that were contributed and 
incompatible by msvc version, finally cmake.  Even, eg, mbedtls and 
wolfssl suffer something similar, they ship with both autotools and 
cmake, but the two are not in sync for options (or sometimes even 
agreeing on the list of sources and being able to build at all in 
mbedtls + cmake case).  There's a lot of evidence this approach is not 
really maintainable.

Libwebsockets moved entirely to cmake five or six years ago, dropping 
the other options and it has been great, it also provides ctest to 
provide crossplatform testing instead of the nest of nonportable bash 
scripts we had before.  In the meanwhile everything else like Android 
build, msvc as you mentioned, iOS, bsds, solaris, cross-build... either 
has first-class cmake support or is now completely predicated around it. 
  CMake won the argument a long time ago.

So I would suggest that making a new release dropping everything except 
cmake is the best way to maintain this.

-Andy

Op ma 2 mei 2022 om 06:50 schreef Andy Green <andy at
warmcat.com>:
> So I would suggest that making a new release dropping everything except
> cmake is the best way to maintain this.
I think there is no harm in maintaining two build systems, it's just
that four is a bit much. There's always one that's forgotten, usually
the Makefile.lite or vcxproj files. I think having both CMake and
autotools has its benefits. I personally like the ease of
cross-compiling with the autotools build system, and make distcheck
seems to have no equal in CMake. The autotools suite on the other hand
can only create Makefiles.