Could users have CFLAGS set to invalid values for zopfli? Is this behaviour normally desired? What do typical linux projects do?

Thank you.

Sure they could set values that have bad effects, but why would they? Anyway it's desired and standard behavior for project build systems to honor user-specified CFLAGS/CXXFLAGS from the environment. In this particular case, users (or distro maintainers) might not be interested in seeing certain types of warnings that the zopfli build emits by default, or might want to use some other optimization level than -O2. All this can obviously already be done, but currently requires modification of Makefile which is unusual and unnecessary.

See #57

@lvandeve One popular thing to do is for some users who compile an application for specifically their system to pass -march=native into the CFLAGS. If the build is to be packaged as a binary for multiple systems of different nature, that flag is undesirable.

Arch Linux has a makepkg.conf option to control custom make flags, but as it states, whether these are respected depends on the build system of the software that is being compiled. Currently, zopfli's makefile does not honour these settings.

Ignoring the question whether using any performance-specific CFLAGS makes a difference, it would be nice of the Makefile to follow the usual practice of allowing this.

Zopfli depends only on the C standard (zopflipng on C++ though). The main goal of the makefile was so that you don't need to recompile everything during development. The compile command for zopfli is now given in the readme. Is it an option for package managers and platforms to depend on the pure C code rather than on makefiles? C looks like to be more portable than makefiles.

It starts to get very messy when there are several executables, libraries etc to take care of. Better to have a working build system in place. But yeah, instead of managing Makefiles by hand and worrying about portability, I suggest something portable that generates them, such as cmake (or autotools).

But anyway, I still do suggest applying this change, cmake or something like it can be done in the future.

@scop it has already been done but not merged, because @lvandeve is not fond of the idea of having build systems besides GNU Make.

Is it an option for package managers and platforms to depend on the pure C code rather than on makefiles? C looks like to be more portable than makefiles.

No. Not having a build system is ludicrous. If people need to tweak a Makefile for their platform, it's still better than not having a Makefile at all. And if a sophisticated enough build system such as autotools or cmake was brought into the mix, platform independence would be a non-issue.

Have a target for a zopfli binary, have a target for a zopfli library, have a target for the zopflipng binary, have a target for the zopflipng library, have a phony target to build all of them, and finally have an install target which installs headers for the libraries and the libraries into well defined locations so people can #include <zopfli.h> or whatever and create a proper symlink from zopfli.so to the version-numbered sonames.

Looks like this was taken care of in 4a35d30