You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
miniz.h right now serves two purposes: generic headers/function prototypes and such, and #defines that the miniz user can change to alter behavior/code size (e.g. #define MINIZ_NO_STDIO).
It'd be ideal for the configuration to live in an entirely separate file to avoid mixing these two purposes. This would also allow users to check their configuration in their own VCS, and copy it & forward-port it when they need to use a newer version of miniz, rather than hand-picking for lines in miniz.h.
Additionally -and this may belong in a separate ticket- for some users it may make sense to not use the amalgated version and instead e.g. add miniz as a git submodule to their project. Given the amalgation process just concatenates the headers and is not actually unifdefing them or anything, it seems like this could be possible (but I may be missing something). In combination with the miniz_config.h split request above, this could perhaps allow for a pattern where one could add "#include "miniz_config.h"\n#include "miniz/miniz.h" in their project's tree (plus some Make code for building miniz.o), and have it do the right thing?
The text was updated successfully, but these errors were encountered:
miniz.h right now serves two purposes: generic headers/function prototypes and such, and #defines that the miniz user can change to alter behavior/code size (e.g.
#define MINIZ_NO_STDIO
).It'd be ideal for the configuration to live in an entirely separate file to avoid mixing these two purposes. This would also allow users to check their configuration in their own VCS, and copy it & forward-port it when they need to use a newer version of miniz, rather than hand-picking for lines in miniz.h.
Additionally -and this may belong in a separate ticket- for some users it may make sense to not use the amalgated version and instead e.g. add miniz as a git submodule to their project. Given the amalgation process just concatenates the headers and is not actually unifdefing them or anything, it seems like this could be possible (but I may be missing something). In combination with the miniz_config.h split request above, this could perhaps allow for a pattern where one could add "#include "miniz_config.h"\n#include "miniz/miniz.h" in their project's tree (plus some Make code for building miniz.o), and have it do the right thing?
The text was updated successfully, but these errors were encountered: