Let's separate out the issues here.
1. There is not, and never will be, support for both Allegro 4.2 and Allegro 4.4. If you want to help with the port to Allegro 4.4, look at branch DD/alleg44. If you want to help with getting the current branch to work with MSYS first, look at the master. We have enough work on our plates without needing to maintain support for multiple versions of the Allego library, for no good reason.
2. CMake vs many different Makefiles: Gleeok is not completely convinced, but, I have to say with all due respect, he's simply wrong. Trying to maintain multiple Makefiles in 2016 is about as crazy as "oh these version control thingies are ok, but let's keep emailing the source back and forth anyway" in 2006. Especially on a large collaborative project involving an unknown number of developers on the Internet rather than a fixed set of employees.
Let's say I shuffle some files around, for example, I add the alleg_compat.cpp fixes that you posted to get ZC to work with Allegro 4.4. In a world where everybody is maintaining their own Makefiles, I know (since I added them) how to correctly add alleg_compat to my own Makefile (an MSVC project, in my case). Everybody else who isn't using my particular Makefile (that includes everyone using MSYS or Linux or OS X) now has a broken build. They will need to figure out how to modify their own Makefiles to correctly add the new .cpp (and of course, there is a nontrivial chance they will add it incorrectly, or in a way that is inconsistent with how I added it in the MSVC project, leading to many pleasant bugs and build issues down the line.) If the Linux developer is inactive for a few month, his Makefile might be many source file updates out of date with the current Windows Makefile. If the Linux developer is a core member of the ZC dev team, maybe they don't mind putting in the work catching up. If it's a random Linux user on the Internet, chances are they will complain here about the broken Makefile instead, or give up trying to patch ZC due to the build system "being broken."
CMake solves these issues. If you make changes to how ZC should be built, you make them in one place and CMake automatically propagates the changes to each individual developer's toolchain and build environment. Gleeok and I get an updated MSVC project. You get an updated gcc Makefile. Etc. Of course, different environments need different build flags, etc, but the CMake file encapsulates these setting in one place, and abstracts out the parts of the build (the list of source files and how they are grouped into modules; the location of the headers; common #defines needed to get Allegro to work, etc) that are common across all platforms.
If you want some concrete evidence, look no further than Allegro itself:
Allegro 4.2: used a ton of different Makefiles and config scripts for different platforms
Allegro 4.4: a single CMake file
Allegro 5.0: a single CMake file
For more success stories see here and an amusing (but accurate) rant about autotools vs CMake here. This blog post also makes the case for CMake. Yes, there are reasons to complain about CMake, and yes, there is some initial pain in setting up the CMake scrpts, but in the long term it solves a lot of problems once we start moving the source code around, switching library versions, etc. Developers who don't happen to use the most popular supported platform (MSVC for Gleeok and I) don't get left in the dust.
If you want to create a private Makefile and use it, I can't stop you (other than wag my finger when something changes in the repository and breaks your Makefile, and then you come here asking for help), but please do not add random Makefiles to the official repository.
There is already a guide for building with CMake in README.md, by the way.
3. MSYS support: I have asked a few times already if anybody wanted MSYS support, and for help configuring the build for MSYS if so, but never heard back from you. I am still happy to do this (that goes for OS X as well). It will require a bit of one-time effort to add the correct configuration options to CMakeLists.txt, but I am willing to do the brunt of the work. Ping me on Skype tonight (I work late but will be available starting at midnight EST) for instance and I can try adding the MSYS config settings in real time.
4. Precompiled libs in the repostory: I completely agree, but I can only compile libraries on the systems that I own (Windows 10 and Ubuntu). I am happy to add libraries for other systems, but I need those supplied to me by developers on those systems to do so.
5. Saffith: Saffith does great work on ZC and I have an incredible amount of respect for him. While I am happy to discuss any aspect of ZC development with him at any time, he indicated he wanted to sit out this particular change and the ensuring drama, and I respect his wishes.
Reply With Quote
Originally Posted by DarkDragon
