tehKaiN
commented
5 years ago https://github.com/vinniefalco/Amalgamate works by default in such way that it includes all files specified by "/path/to/file" but not <path/to/file> which is a good approach since it differentiates lib's internal includes from OS includes. Still, we use #include <ace/stuff.h> in our engine's files since vbcc is messed up in regard of determining where base of " include is.
You can enable <> inclusion during amalgamation by passing -s switch, but it would produce amalgamated lib specific to given environment, so we a) stick to that, b) change includes to " scrapping vbcc support, c) rework amalgamation tool so that one can specify which <> includes should be included and which not by e.g. passing regex
https://github.com/vinniefalco/Amalgamate this can join libraries into one huge-ass .c / .h pair. It's proven to work on freetype and other stuff. It lacks proper documentation as seen in https://github.com/vinniefalco/Amalgamate/issues/7
I did some research and it's not automagical as it seems. https://github.com/vinniefalco/Amalgams is a repo containing "amalgamation templates" which are .c and .h files which are including project's .c and .h files respectively into single file. Then you call
amalgamatewith it.I've seen other amalgamation tool on GH but it's on python. having it in C/C++ would be a blast 'cause it could build itself during ACE's build process and generate amalgamation in completely transparent way for the end user. What I don't like is the semi-automatic approach using template files and JUCE dependency.
@approxit share your thoughts.