>>> The real issue with external dependencies is about upgrading. [...]
>> For my use-case vulnerabilities are a non-issue. > Okay; but my point was rather the reverse: that the only real reason > you'd want an external dependency is for the fixes; if you do not care > (and provided the redistribution licenses are in agreement), then > embedding the source is the way to go. But the form does not change that > substancially (I am not sure the fact an updating commit is lasting 1 or > 200 seconds is the most important thing here.) If someone gets my demo app and they want to use it as the foundation for a new project, then every time FreeType has changes, the process for retrieving an update is more complicated, if there are new files, renamed files, or removed files. It is not obvious from looking at just the FreeType source tree which .c files actually get compiled, versus which .c files are simply included. Furthermore, creating a new project that used a deep copy of the FreeType source tree (so that the published project was self contained) is more elaborate than creating a new project that uses an amalgamation (which is as easy as adding two files). The amalgamated distribution format is more convenient for the use-cases contemplated. > >>> What is important on this respect OTOH, is that the amalgamationprocess >>> be realised by the Freetype project, and released through it: that way >>> any recommended upgrade could be made available with lowest delay. >> I'm not so sure this is important. The amalgamation should require only >> minor cosmetic changes to the FreeType sources. It should be possible to >> recreate an amalgamation using a simple automated tool. > Here you lost me. Are you saying that we should change the Freetype > tree, in order to allow random amalgamation tools to be run against it > by users (like you)? Not sure what you mean by changing the tree. Flattening all the sources? No that shouldn't be needed. The problem with ftconfig.h is more involved, there would need to be a preamble that decodes the platform, and then all the different incarnations of ftconfig.h rolled into one header that has conditional preprocessing directives. > What exactly is wrong (from the point of view of the user, of course) > with my proposal to have the Freetype project providing such a tool, > tailored to the specificities of Freetype? >From the user's perspective nothing, but putting FreeType specific smarts into a separate tool, to me seems like misplaced effort. Better that the FreeType sources are tweaked, this increases the chances that the amalgamated sources will work in more environments without requiring changes to a build tool. I'm not a fan of build tools, they are just another piece of software that can break. Ideally, the existing Juce amalgamator tool would work (its not Juce-specific). I'm having a little bit of success with using this tool. I have created a file ftamalgam_template.c this is the contents: /* This template file is the input to the amalgamator */ /* internal headers */ #include <freetype/internal/ftobjs.h> #include <freetype/fttypes.h> /* sources */ #include "src/autofit/aftypes.h" #include "src/autofit/afdummy.h" #include "src/autofit/aflatin.h" #include "src/autofit/afcjk.h" #include "src/autofit/afindic.h" #include "src/autofit/autofit.c" #include "src/bdf/bdf.c" #include "src/cff/cfftypes.h" #include "src/cff/cffparse.h" #include "src/cff/cff.c" #include "src/base/ftbase.c" #include "src/base/ftbitmap.c" #include "src/cache/ftcache.c" #include "src/base/ftdebug.c" #include "src/base/ftfstype.c" #include "src/base/ftgasp.c" #include "src/base/ftglyph.c" #include "src/gzip/ftgzip.c" #include "src/base/ftinit.c" #include "src/lzw/ftlzw.c" #include "src/base/ftsystem.c" #include "src/smooth/smooth.c" /* modules */ #include "src/base/ftbbox.c" #include "src/base/ftmm.c" #include "src/base/ftpfr.c" #include "src/base/ftsynth.c" #include "src/base/fttype1.c" #include "src/base/ftwinfnt.c" /*#include "src/pcf/pcf.c"*/ /* THIS BREAKS */ Unfortunately when the amalgamated result is compiled, I get a cryptic error with FT_ULong. And I have not addressed the problem of macros appearing in include lines, or the use of angle brackets. But its a start. >>> Isn't already autoconf (well, really configure) task on Unix-like > targets? >> Most of what autoconf does can be achieved by detecting the platform. > The same can be said of the "make config.mk" (first) step of the > semi-automated GNU make architecture, or of Jam. > As Werner noted earlier, the striking point in nowadays Freetype is that > the builds/*/*.mk fragments are not much updated (with Microsoft quickly > moving targets as an important exception...) At the risk of losing credibility I will admit that I have never actually used autoconf and I have no idea what mk fragments are. All of my experiences with using these tools have been negative. When I download sources and I see those files it brings a bad taste to my mouth. All of my development is done on Windows in Visual Studio. I use XCode for testing Macintosh and iOS builds, and rely on my users for the rest. I much prefer that intelligence about handling platform specifics be embedded in the header files and detected through the use of preprocessor directives. This is the approach used by Juce and sqlite. It has the benefit that fewer tools are involved in the build pipeline, and thus less things to break. And when there is a build problem, it is isolated to a smaller number of components so there is less to search for the defect. Designing a library's sources so that pre-build steps are not necessary also lets you reach a wider audience - it is a fact that external dependencies cause you to lose some non zero percentage users. Namely, those that can't be bothered to install or don't know how to use the additional tools. _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
