Re: [ft-devel] FreeType Amalgamation: What to do?
> So is the CFF stuff finalized? It seems that the 64bit issues have been resolved, and that I'll do a release in the next few days. > I would just have to add the items in src/cff (and md5.c)? Yes. The CHANGES file says how to activate the new CFF engine until it becomes the new default. Werner c ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType Amalgamation with CFF changes
Well...I updated the amalgamation to the tip of the master branch from the FreeType repository, to include the recent CFF changes. The files in src/cff seemed to be included, after I added the necessary macro substitution for FT_CFF_DRIVER_H. So, if anyone would like to try it and let me know if there are issues with it that would be great, since I have no meaningful way of testing it other than making sure it compiles and links. It's in the "with-cff-changes" branch: https://github.com/vinniefalco/FreeTypeAmalgam/tree/with-cff-changes If this works I will move it to "develop" and then when FreeType 2.4.12 is officially released I will migrate it to "master." Thanks! -- Follow me on Github: https://github.com/vinniefalco ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType Amalgamation: What to do?
Hey guys, I'm a little late to the party. It looks like a lot of exciting things have been happening! I need to bring the amalgamation up to date. So is the CFF stuff finalized? I would just have to add the items in src/cff (and md5.c)? Thanks! -- Follow me on Github: https://github.com/vinniefalco ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType Amalgamation 2.4.10rc1 Available!
FreeType Amalgamation 2.4.10rc1 is now available, based on VER-2-4-10 of the official FreeType repository. It is available in the 'develop' branch of the FreeTypeAmalgam repository: https://github.com/vinniefalco/FreeTypeAmalgam The tag is VER-2-4-10-rc1 Please open issues as needed if there are any problems with this version of the amalgamation in your build environment. If there are no problems reported, the 'master' branch will be updated to the release candidate in one week. Thanks! ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation UPDATED!
> I've updated the amalgamated version of FreeType, [...] Anything which I should take care of? Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType Amalgamation UPDATED!
I've updated the amalgamated version of FreeType, these are the changes: - The amalgamated repo is at https://github.com/vinniefalco/FreeTypeAmalgam - The repo no longer includes the templates - The directory structure has been flattened to make it easier to view - A file called COMMITLOG contains the full commit log of the branch of FreeType that was used to produce the corresponding amalgamated sources - The amalgamated files include the copyright and licensing terms at the top - The repo contains the license files - FreeTypeAmalgam.h provides ftglyph.h now The templates for building the FreeType amalgamation are in their own repository now, with these improvements: - The template repo is at https://github.com/vinniefalco/FreeTypeAmalgamTemplate - The script has been re-written to use the Bourne shell and placed in platform-independent location. - The Visual Studio 2010 project automatically creates the amalgamation as a pre-build step. - The amalgamation script automates production of COMMITLOG - Licensing terms (MIT license) were made clear The Amalgamate tool has also received some changes - The Amalgamate tool repo is at https://github.com/vinniefalco/Amalgamate - The directory structure has been flattened to make it easier to view and compile - The included JUCE module was shrunk down in size - The tool is cross platform (always was), it should be possible to just compile the two .cpp files and link them to create the binary. - Licensing terms were made clear Thanks ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType Amalgamation
I've moved the FreeType amalgamation over to github. You can access it here: https://github.com/vinniefalco/FreeTypeAmalgam The amalgamation tool has also been moved to github, at: https://github.com/vinniefalco/Amalgamate Comments welcome, Thanks.___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation first draft
>Date: Wed, 22 Feb 2012 16:54:00 -0800 >From: "Tom Bishop, Wenlin Institute" > >It works! Awesome! Thank you Vinnie! Glad to hear it! >One question: my application normally includes ftoutln.h, for directly calling >FT_Outline_Render(), etc. With FreeTypeAmalgam.h and FreeTypeAmalgam.c, > I don't include ftoutln.h and I get: > > warning: implicit declaration of function ?FT_Outline_Render? > >In spite of the warning, it seems to compile and run correctly. >From studying the code and your use-case now I see that there are some header files which are part of FreeType that must be included manually in order to get functionality (such as ftoutln.h). You are right not to include ftoutln.h when using the amalgamation - that file doesn't exist! This is fixed by adding all of these "optional" headers into FreeTypeAmalgamTemplate.h before running the amalgamation tool. I added ftoutlin.h and updated the amalgamation in the Google Code repo, give it a whirl if you would like: http://code.google.com/p/amalgamate/source/browse/#svn%2Ftrunk%2FFreeType If anyone can help me build a comprehensive list of these optional headers I can go ahead and add them to the amalgamation. Please note this is just a first iteration. One of my users is already bringing up an issue, that it would be nice to have some additional conditional compilation directives in the amalgamation itself to control which modules are available. The amalgamation would still have "all the code" but the separate "FreeTypeConfig.h" could turn parts off (to make the resulting binary smaller). Thanks ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation first draft
It works! Awesome! Thank you Vinnie! One question: my application normally includes ftoutln.h, for directly calling FT_Outline_Render(), etc. With FreeTypeAmalgam.h and FreeTypeAmalgam.c, I don't include ftoutln.h and I get: warning: implicit declaration of function ‘FT_Outline_Render’ In spite of the warning, it seems to compile and run correctly. Any suggestion on how to obtain the declarations that are normally in ftoutln.h? Thanks again and best wishes, Tom On Feb 21, 2012, at 1:59 PM, Vinnie wrote: > Well here it is, an amalgamated version of FreeType. It compiles, links, and > functions correctly in my host application (which was previously linking with > a version of FreeType built as a static library from the full source tree on > my machine). This is only a first draft, plenty of rough edges here (but it > works!) > > http://code.google.com/p/amalgamate/source/browse/#svn%2Ftrunk%2FFreeType > > Just two files, FreeTypeAmalgam.h and FreeTypeAmalgam.c > > ___ > Freetype-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/freetype-devel > 文林 Wenlin Institute, Inc.Software for Learning Chinese E-mail: [email protected] Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType Amalgamation first draft
Well here it is, an amalgamated version of FreeType. It compiles, links, and functions correctly in my host application (which was previously linking with a version of FreeType built as a static library from the full source tree on my machine). This is only a first draft, plenty of rough edges here (but it works!) http://code.google.com/p/amalgamate/source/browse/#svn%2Ftrunk%2FFreeType Just two files, FreeTypeAmalgam.h and FreeTypeAmalgam.c ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
Vinnie wrote:
> I've been wracking my brains and trying to come up with every possibility
> but I have given up - what is the utility of these lines:
>
> #ifdef FT2_BUILD_LIBRARY
> #define FT_INTERNAL_INTERNAL_H
> #include FT_INTERNAL_INTERNAL_H
> #endif /* FT2_BUILD_LIBRARY */
>
> versus
>
> #ifdef FT2_BUILD_LIBRARY
> #include
> #endif
>
> ???
Allowing to work "dump" sed scripts such as
/^#define/{
s,https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
Amalgamation tool is here: http://code.google.com/p/amalgamate/ >I repeat it: It's not possible to make FreeType work on all platforms >with preprocessor macros only. I'm not so sure about that. I looked at all of the stuff in the builds directory and it would seem that the bulk of platform differences have nothing to do with the code but rather, the build tools. With the amalgamated distribution format, the work of setting up the build environment is offloaded onto the programmer. It is assumed that they already have a project that builds correctly, so to use the amalgamation they only need to add an additional .c file to the already-working project. >> 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. > >Again, this is the Windows philosophy...Every project/program must >come with everything it needs. No chance to reuse...components reliably. Yes, and I would call this a feature rather than a deficiency. I WANT my app to come with everything it needs, this way it always behaves predictably. That's why I link with the C runtime statically, instead of opening myself up to the mess caused by shared libraries (a.k.a. "DLL hell"). >However, given that FreeType is used in virtually all smartphones, >reaching a wider audience is probably not a big issue for us :-) Well when I speak of audience I am talking about the programmers and not the devices on which the application runs. Here is a typical use-case: 1) Musician (the user) discovers DAW (digital audio workstation) software like ProTools 2) User learns about audio plugins which can produce filtered effects and also act as synthesizers or sequencers. 3) User decides they want to write their own plugin and starts reading up. 4) User realizes they must first learn C/C++, and downloads an existing open source plugin to see how it works. So this is the typical user for a Freetype amalgamation. 90% of the time they are running on a Mac OS X workstation or laptop that has some music software installed. The other 10% are running on Windows, and will end up downloading Visual Studio Express (the free version) to try their hand at plugin authoring. Most of these plugins are written using a framework like Juce, that handles almost all of the plugin format specific details, as well as all of the platform specific details. Juce has a robust API for putting up a fancy gui, with the benefit that this gui works on all platforms. Plugin authors always want to have very fancy interfaces with realistic looking knobs, sliders, and meters with color blends, shadows, and transparency effects but equally importantly the display of crisp text at small point sizes and thats where FreeType comes in. To gain complete control over the gui and make sure that pixels always land in the right place, instead of relying on a system provided font (which may or may not exist) fonts are embedded in the plugin or host application and used consistently, ensuring that the layout of gui elements is always predictable. >> The amalgamation should work with all platforms that FreeType >> currently supports, of course! > > This, I believe, is an illusion. You'll certainly find a compiler > which fails to compile without proper autoconf configuration. Maybe > it's better to restrict amalgamation on a subset of supported > platforms. Well like I said, looking through the ./builds/ directory it seems that almost all of the platform differences are related to the build environment and not C language / compiler specifics. Since a requirement of the amalgamation is that the user provide an already-working project in which to drop the large .c, this becomes a non-issue. > Is your amalgamation tool freely available source code which I can > build by myself on GNU/Linux? Yes it is. The tool is based on the Juce amalgamator, with some of my own additions to support FreeType. I made the new features as general as possible - there is nothing specific to FreeType in it. In particular, I added all of the command line switches -d, -i, -w, -s. You can get the sources here: http://code.google.com/p/amalgamate/ Don't expect miracles, I started a day ago. There is only a Visual Studio 2010 project file, but you should be able to build it under your favorite platform by compiling the .cpp files and linking them with the right libraries. There is a "FreeType" directory in the repository that has the FreeType amalgamated template, as well as a batch script that calls the amalgamation tool with suitable parameters. On my machine I am able to produce an amalgamation that compiles. I had to make the changes I wrote about in previous posts, regarding duplicate symbols. There is one lingering issue with fterror.h, since it gets included multiple times. I'm not sure how I will fix it. > Having a `make amalgamation' target within Free
Re: [ft-devel] FreeType Amalgamation (changes)
> Rename Load_Glyph() static function as it conflicts with another > static function. [...] This is just touching the tip of the iceberg. Functions and structures in FreeType should be renamed everywhere to be consistent: functions local to a file: __ otherwise: __ `Load_Glyph' in `ttdriver.c' should thus be called `ttdriver_glyph_load'. In `cffdrivr.c', the name should be `cffdriver_glyph_load'. Again, please send patches! > 5) Where are ftimage.h and inttypes.h? This is special. Please read the comment at the top of `ftraster.c'; the direct inclusion of those files (not using macro names) only happens in stand-alone mode. Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
> So here are some of the issues I am coming up with producing the > amalgamation: > > 1) Duplicate symbol name TBand_ in ftraster.c and ftgrays.c > > Solution is to rename one. Yep. Stuff from `ftgrays.c' and `ftraster.c' should have `gray_' and `black_' as prefix, respectively. Note that these two components are somewhat special since you can use them separately, this is, outside of FreeType. > 2) Duplicate macro definitions: FLOOR, CEILING, TRUNC, SCALED in >ftraster.c and ftgrays.c > > I added these lines in both files, before the #define statements: > > #ifdef FLOOR > #undef FLOOR > #endif > #ifdef CEILING > #undef CEILING > #endif > #ifdef TRUNC > #undef TRUNC > #endif > #ifdef SCALED > #undef SCALED > #endif This looks OK. BTW, it should be sufficient to say #undef FLOOR #undef CEILING #undef TRUNC #undef SCALED > 3) Duplicate symbol name TWorker_ in ftraster.c and ftgrays.c > > Again the solution, rename one of them. Yes, see above. > 4) Macro conflict with RAS_ARG, RAS_ARGS, RAS_VAR, RAS_VARS, > RAS_VAR_, RAS_ARG_ in ftraster.c and ftgrays.c > > Solution is to #ifdef / #undef these macros before they are > redefined. I rather prefer renaming as above. > 5) Duplicate symbol TRaster_ in ftraster.c and ftgrays.c > > Solution is to rename one. Yes. > This is what I mean by "cosmetic" changes. It looks like ftgrays.c > was born as a copy of the file ftraster.c and modified > appropriately, thus the duplicate symbol names. Indeed. Can you provide patches, splitting the discussed issues into logical change sets so that I can easily add them to the git repository? I suppose that you have git support installed... And can you provide proper ChangeLog entries also (following the format given in this file)? Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
> I've been wracking my brains and trying to come up with every > possibility but I have given up - what is the utility of these > lines: > > #ifdef FT2_BUILD_LIBRARY > #define FT_INTERNAL_INTERNAL_H > #include FT_INTERNAL_INTERNAL_H > #endif /* FT2_BUILD_LIBRARY */ > > versus > > #ifdef FT2_BUILD_LIBRARY > #include > #endif Well, yes, this is probably overkill. It is done for orthogonality only, giving `internal.h' a macro name also. > Also, who sets macros like FT_INCREMENTAL_H other than ftheader.h? Those macros are static, to be changed manually only if the include header file locations are changed. Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
> 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. What about reading the docs? The complete list is in INSTALL.ANY! > 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). IMHO, this is a severe deficiency of MS Visual Studio (and probably other similar GUI tools) which forces you to `register' files. The Unix philosophy to build with the standard command line incantation ./configure make make install is completely different and doesn't need this approach. On Unix, using the standard build tools (autoconf, automake, libtool, make), adding a complete directory hierarchy is very cheap. I know this isn't something you can change, so please consider the above as a side note only. > 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. `.mk' is often used as the file name extension of sub-Makeiles which get included by the main Makefile > 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 fully believe you. Since the Windows command line interpreter is nearly unusable for serious shell scripting, you need a better shell. Then you need a bundle of additional text tools the shell scripts rely on. Only recently support for MSVC has been added to some GNU tools -- this compiler's command line options are very different and limited. And so on. However, Visual Studio is just *one* possibility of a workflow, and we try to support more. And I repeat it: It's not possible to make FreeType work on all platforms with preprocessor macros only. > 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. Again, this is the Windows philosophy, since this OS lacks a serious package management. Every project/program must come with everything it needs. No chance to reuse any third-party components reliably. We have to live with that, and it is good that developers like you are interested in making FreeType work better under such circumstances. However, given that FreeType is used in virtually all smartphones, reaching a wider audience is probably not a big issue for us :-) Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
>>...there are several macros that would not work if all sources are >>concatenated. ...An example is GET_PIC() macro defined by >>src/xxx/yyypic.h. and src/xxx/ttpic.h > > Isn't this easily fixed by renaming one of the #define and changing > the appropriate source files? We will do so. >>I neither have time nor energy to change that. It's there since ten >>years, and it works essentially everywhere. Note that there are >>other packages which do similar things, for example `boost'. > > Sure, but it gets in the way of an amalgamation. It can be worked > around though. However, what is the purpose? Is there ever a > situation where FT_GLYPH_H is defined to something other than what > exists in the header file? The user has the flexibility to do so. With a specially crafted ftheader.h file, you can e.g. put all header files into one directory, both at build time and after installation. >>How shall this work? There are dozens of platforms, and you want to >>hard-code them all in a configuration header file? > > Yes, that is the hope. This is the approach taken by boost. Maybe this works for C++ since it is a newer, stricter standard, but for C I fear you'll find a platform where this fails. > The amalgamation should work with all platforms that FreeType > currently supports, of course! This, I believe, is an illusion. You'll certainly find a compiler which fails to compile without proper autoconf configuration. Maybe it's better to restrict amalgamation on a subset of supported platforms. > Well nice suggestion but this doesn't get us much. I prefer a > requirement of passing -l flags to the amalgamation tool to inform > it of all the directories to search for includes, because this way > someone who wants to produce an amalgamation does not have to > re-shuffle the FreeType source tree after they check it out. Is your amalgamation tool freely available source code which I can build by myself on GNU/Linux? Having a `make amalgamation' target within FreeType is the right route to go IMHO. Whether this uses your tool or another one (possibly hand-crafted) is not so important. >>There were good reasons for it which you might look up in the >>archives. > > How do I look this up? The list archive is here: http://lists.gnu.org/archive/html/freetype-devel/ Here David has announced the change: http://lists.gnu.org/archive/html/freetype-devel/2000-12/msg00025.html The corresponding commit in the git repository is 8fba32d2d6f284bfd49ed6c0557880e0bb692f49 Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation (changes)
More cosmetic changes I had to make: 1) ttdriver.c Rename Load_Glyph() static function as it conflicts with another static function. 2) t1driver.c Rename t1_get_glyph_name() as it conflicts with another static function. 3) cidload.c Rename parse_font_matrix(), t1_init_loader(), t1_done_loader(), 4) FT_ERRORS_H Before any lines that #define FT_ERR_PREFIX or FT_ERR_BASE, these lines need to be added: #ifdef FT_ERR_PREFIX #undef FT_ERR_PREFIX #endif #ifdef FT_ERR_BASE #undef FT_ERR_BASE #endif 5) Where are ftimage.h and inttypes.h? There are some lines that include these but they don't seem to be in the source tree. Dead code? ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
So here are some of the issues I am coming up with producing the amalgamation: 1) Duplicate symbol name TBand_ in ftraster.c and ftgrays.c Solution is to rename one. 2) Duplicate macro definitions: FLOOR, CEILING, TRUNC, SCALED in ftraster.c and ftgrays.c I added these lines in both files, before the #define statements: #ifdef FLOOR #undef FLOOR #endif #ifdef CEILING #undef CEILING #endif #ifdef TRUNC #undef TRUNC #endif #ifdef SCALED #undef SCALED #endif 3) Duplicate symbol name TWorker_ in ftraster.c and ftgrays.c Again the solution, rename one of them. PWorker will also have to be renamed since its an alias for TWorker_ *. 4) Macro conflict with RAS_ARG, RAS_ARGS, RAS_VAR, RAS_VARS, RAS_VAR_, RAS_ARG_ in ftraster.c and ftgrays.c Solution is to #ifdef / #undef these macros before they are redefined. 5) Duplicate symbol TRaster_ in ftraster.c and ftgrays.c Solution is to rename one. PRaster will also have to be renamed since its an alias. This is what I mean by "cosmetic" changes. It looks like ftgrays.c was born as a copy of the file ftraster.c and modified appropriately, thus the duplicate symbol names. Thanks, Vinnie ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
I've been wracking my brains and trying to come up with every possibility but I have given up - what is the utility of these lines: #ifdef FT2_BUILD_LIBRARY #define FT_INTERNAL_INTERNAL_H #include FT_INTERNAL_INTERNAL_H #endif /* FT2_BUILD_LIBRARY */ versus #ifdef FT2_BUILD_LIBRARY #include #endif ??? Also, who sets macros like FT_INCREMENTAL_H other than ftheader.h? ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
>>> 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 #include /* 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
Re: [ft-devel] FreeType Amalgamation
Vinnie wrote: >> Not sure I understand all the point, but it seems to me an issue at >> software engineering here. > The current use-case for FreeType, and what I believe that developers > here have the most experience with, is as a shared library on a GNU/Linux > type system. > > My use-case, and that of my users, is to link with FreeType statically I am sure there are also real users of statically-linked Freetype still lurking around (beyond you, that is); also David certainly was such an user when he set it up. >> 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.) >> 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)? 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? >> 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...) Antoine ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
>> I'm afraid that MacOS specific ugly hacks (detecting Mac OS, >> excluding CodeWarrior, detecting Mac OS X, excluding PPC, excluding >> 64bit, etc etc) made Vinnie feel sick. > > I don't think so :-) If I understand him correctly, he would like to > configure everything with platform-dependent macros in a single header > file. Yes that's right. As Werner said, I would like all of the configuration to happen during the preprocessing phase and not in a separate configuration step, automated or otherwise. >>...For Freetype 2 (b. 1999), David went away from this scheme, in my eyes >> for the benefit of a much increased modularity > I do not know if it still useful. Voices? It should be possible to produce an amalgamated version of FreeType that requires only cosmetic changes to the source tree. Certainly nothing radical. It is not necessary or desirable to change FreeType's current structure, which consists of modules. > Not sure I understand all the point, but it seems to me an issue at > software engineering here. The current use-case for FreeType, and what I believe that developers here have the most experience with, is as a shared library on a GNU/Linux type system. My use-case, and that of my users, is to link with FreeType statically (i.e. it is "baked in" to the application). We then embed a font directly in the application. For example, by using an automated tool that converts a binary file (the font file) into a static variable in a .c file defined as an array of bytes. The font is loaded at run-time using the statically linked FreeType. Note that even on a Linux system, FreeType is still linked into the application statically, and we DO NOT directly use the FreeType shared library that is already on the platform. However, if the X11 window system or underlying graphics layer uses FreeType, we might indirectly use FreeType (if we use fonts other than those embedded in the application). The reason that we want to use a statically linked version of FreeType is for regression and testing. There is no possibility of a different version of the library getting used: we know that the end-user experience is not going to change. With FreeType in conjunction with Juce it is possible to develop a gui application that runs on Windows, MacOS, iOS, and Android devices and looks the same for all the platforms. I needed FreeType to get hinted output in Juce for small sizes of my font. This is the code I wrote: http://rawmaterialsoftware.com/viewtopic.php?f=6&t=6393 > The real issue with external dependencies is about upgrading. If we have > a look over the last 10 years of Freetype history as condensed into > docs/CHANGES, most version bumps are either bugfixes for some previously > introduced changes, or vulnerabilities fixes. Both are good reasons to > upgrade as soon as possible the version of Freetype in use. For my use-case vulnerabilities are a non-issue. The user never has the opportunity to choose a font file. If there is a bugfix, then the amalgamation is recreated, the client application is rebuilt, and a new version distributed. > 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. I am using the Juce amalgamator as the starting point. It is the one I used to produce the Juce amalgamation in DSP Filters Demo. > This is in opposition to a in-house flattening of the Freetype tree integrated > into a bigger project, where any further upgrade is then dependent on that > developer willingness and availability... Right, and developer willingness is exactly what should drive the upgrade process of the amalgamation. The simple fact is that since I started using FreeType 2 years ago, none of the bug fixes or patches has helped me. But don't stop the fixes on account of me! It's just that I'm using FreeType in a very narrow use-case. Specifically, I'm using FreeType to load my own font embedded in the application, extract hinted outlines, and draw it using the Juce renderer. >> True, this could be done by creating a deep clone of the entire FreeType >> source tree but this is a bulky solution. > > I am not sure this is as bulky as you seem to imply. Yeah its pretty bulky, because every time FreeType changes, anyone who is redistributing the sources has to commit several files instead of just one or two. What happens when a file is added, moved, or renamed? Anyone who has added FreeType to their project as a set of sources may need to maintain their project file. Compare and contrast this with an amalgamation. For most of the latest FreeType fixes, only one file would have changed (the big .c). > Something I do see as bulky thoug
Re: [ft-devel] FreeType Amalgamation
On Fri, Jan 20, 2012 at 12:39 PM, Vinnie wrote: > > Just wanted to chime in to say that I've been using ft on an embedded > > > system for a year or more now. Went the library route so I build a > > libfreetype.a and had no trouble with this. Not really sure what the > desire > > to have an amalgamation is. > > The goal of an amalgamation is to make it possible for a developer to > distribute full sources for an application, while requiring no external > dependencies or added build steps. > > DSP Filters Demo is an example of such an application: > http://code.google.com/p/dspfilterscpp/ > > You can pick up the sources and build the thing without having to download > or checkout anything else, using these lines: > > unzip DSPFiltersComplete_0_9_72.zip > cd shared > g++ -o dspfiltersdemo $(find DSPFiltersDemo DSPFilters -name \*.cpp) > JuceAmalgam/JuceLibraryCode*. > cpp -I JuceAmalgam -I DSPFiltersDemo/source/ -I DSPFilters/include/ > $(pkg-config --cflags --libs freetype2 alsa) -ldl -lpthread -lrt -lX11 -lGL > -lGLU -lXinerama -lXext > > The included project files for XCode and Visual Studio allow you to build > the > demo for MacOS X, iOS, Windows, and Android devices, without any > configuration or pre-build steps. > > I want to add support for my Juce hinted font output. These are my sources > for producing hinted output: > > http://rawmaterialsoftware.com/viewtopic.php?f=6&t=6393 > > If I add this code to my DSP Filters Demo, it will break the feature that > the demo requires no external dependencies. In order to compile and link > the demo with this class, it will be necessary to check out the FreeType > sources, build it for the platform, then add some platform-specific magic > words to the project, Makefile, or whatever was used to compile the demo. > > On the other hand, with an amalgamation, I would be able to just add > something like FreeTypeAmalgamation.h, FreeTypeAmalgamation.cpp to my > sources, include the .h file, add the .cpp to the project (the build > snippet > I gave above would automatically work with this addition) and compile > and link. Of course I would also need to embed a hinted font in my app. > > The resulting demo would always look and function predictably, even if > the FreeType shared library on the target system was a different > version (because Juce performs all of its own text and graphics drawing > instead of using the system). > > Could ship the libraries along with the rest of the source or require that they be available on the system. This is easy on Linux but a pain on Windows where there isn't really a package management system. Having an amalgamated version doesn't impact me any since most of my stuff requires several external libraries. I just ship with the precompiled libraries. > > Wouldn't be opposed to cleaning things up to make it possible to build an > > amalgamation but from past use of sqlite it was a real pain trying to > merge > > c++ code into sqlite due to the amalgamated approach. > > What exactly was the issue with sqlite? I added encryption to it which required stubbing in functions for memory or block allocation. I don't recall the specifics but it was related to the c++ compiler and including sqlite headers in c++ code I think. I got it working but it wasn't trivial to integrate the build setup. Chris ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
> Just wanted to chime in to say that I've been using ft on an embedded > system for a year or more now. Went the library route so I build a > libfreetype.a and had no trouble with this. Not really sure what the desire > to have an amalgamation is. The goal of an amalgamation is to make it possible for a developer to distribute full sources for an application, while requiring no external dependencies or added build steps. DSP Filters Demo is an example of such an application: http://code.google.com/p/dspfilterscpp/ You can pick up the sources and build the thing without having to download or checkout anything else, using these lines: unzip DSPFiltersComplete_0_9_72.zip cd shared g++ -o dspfiltersdemo $(find DSPFiltersDemo DSPFilters -name \*.cpp) JuceAmalgam/JuceLibraryCode*. cpp -I JuceAmalgam -I DSPFiltersDemo/source/ -I DSPFilters/include/ $(pkg-config --cflags --libs freetype2 alsa) -ldl -lpthread -lrt -lX11 -lGL -lGLU -lXinerama -lXext The included project files for XCode and Visual Studio allow you to build the demo for MacOS X, iOS, Windows, and Android devices, without any configuration or pre-build steps. I want to add support for my Juce hinted font output. These are my sources for producing hinted output: http://rawmaterialsoftware.com/viewtopic.php?f=6&t=6393 If I add this code to my DSP Filters Demo, it will break the feature that the demo requires no external dependencies. In order to compile and link the demo with this class, it will be necessary to check out the FreeType sources, build it for the platform, then add some platform-specific magic words to the project, Makefile, or whatever was used to compile the demo. On the other hand, with an amalgamation, I would be able to just add something like FreeTypeAmalgamation.h, FreeTypeAmalgamation.cpp to my sources, include the .h file, add the .cpp to the project (the build snippet I gave above would automatically work with this addition) and compile and link. Of course I would also need to embed a hinted font in my app. The resulting demo would always look and function predictably, even if the FreeType shared library on the target system was a different version (because Juce performs all of its own text and graphics drawing instead of using the system). > Wouldn't be opposed to cleaning things up to make it possible to build an > amalgamation but from past use of sqlite it was a real pain trying to merge > c++ code into sqlite due to the amalgamated approach. What exactly was the issue with sqlite? Thanks Vinnie ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
Just wanted to chime in to say that I've been using ft on an embedded system for a year or more now. Went the library route so I build a libfreetype.a and had no trouble with this. Not really sure what the desire to have an amalgamation is. Wouldn't be opposed to cleaning things up to make it possible to build an amalgamation but from past use of sqlite it was a real pain trying to merge c++ code into sqlite due to the amalgamated approach. Chris On Fri, Jan 20, 2012 at 11:50 AM, Vinnie wrote: > >...I add twenty-five FreeType C files directly to the project or > makefile... > >...It is tedious since they are in a bunch of different folders that also > >...contain other C files that should NOT be added. > > I have noticed this as well. The only way to figure out which .c are > actually > needed is to consult the project file or Makefile. > > >...there are several macros that would not work if all sources are > concatenated. > >...An example is GET_PIC() macro defined by src/xxx/yyypic.h. and > src/xxx/ttpic.h > > Isn't this easily fixed by renaming one of the #define and changing the > appropriate > source files? > > >When I found them, I could not decide which is appropriate direction > quickly; > >giving some prefix/suffix to separate them to different namespaces, or the > >insertions of "#undef GET_PIC" macros. > > What's wrong with #define GET_PIC and #define GET_PIC2 (for example)? At > least this way the identifiers are unique and you can distinguish them in > a search. > > >Can you use this? > >http://www.cs.berkeley.edu/~necula/cil/merger.html > > This is a nifty program but it doesn't produce an amalgamation. In order > for the > resulting amalgamation to retain all of the original functionality, the C > preprocessor > should NOT be run on the sources. Directives need to remain intact. Well, > except > for certain #include lines (which cause the file to get inserted on the > first occurrence). > > >Such an approach would make the output more difficult to edit directly > >though, so it would then really only be meant to be regenerated when > >changes are made to the original source. > > An amalgamation is never edited directly. It is always recreated from the > original sources. > > >> 1) Some FreeType #include statements use angle brackets instead of > >> double quotes. e.g. #include Why? > > > >This is to control inclusion with the -I command line flag of the > >compiler. Think of build_dir != src_dir (which is very common on Unix > >boxes). > > I understand the angle brackets now. It is because there are several > versions of ft2build.h. If we roll them all together into a single file > with > appropriate preprocessor directives to decode the platform then the > angle brackets would no longer be necessary, since there would only > be one file. > > >> 2) Some FreeType #include statements use macros, like "#include > >> FT_GLYPH_H". This complicates automated tools. > > > >I neither have time nor energy to change that. It's there since ten > >years, and it works essentially everywhere. Note that there are other > >packages which do similar things, for example `boost'. > > Sure, but it gets in the way of an amalgamation. It can be worked around > though. However, what is the purpose? Is there ever a situation where > FT_GLYPH_H is defined to something other than what exists in the > header file? > > >> 3) A new ftconfig.h should be created that has a preamble for > >> decoding the platform, [...] > > > >How shall this work? There are dozens of platforms, and you want to > >hard-code them all in a configuration header file? > > Yes, that is the hope. This is the approach taken by boost. > > >Let me ask it differently: What platforms are you going to support? A > >generic solution needs configuration done by an external tool > >(e.g. autoconf), but this somehow contradicts your idea of simply > >having everything in a large file.[1] > > The amalgamation should work with all platforms that FreeType currently > supports, of course! Requiring autoconf also contradicts the purpose of > this. It should be possible to just "drop in" the amalgamation, to an > existing > project, without running any separate tools. This way, when someone > publishes an application that uses the FreeType amalgamation, anyone > who wants to build it can just pick up the sources, open the project, > and press the "build button" (figuratively) - no separate tools, > dependencies, > or configuration is needed. > > >Given the many problems, I suggest a step-by-step approach, and I hope > >that you can assist, test, and develop. > > Yes I agree. It's good to know about GET_PIC, that would trip up the > amalgamation. But it is easily fixed. The issue with the #include lines is > also fixable, for example: > > amalgamator.exe -d FT_GLYPH_H=src/ftglyph.h ... > > It could be a requirement of the amalgamation tool that macros used in > #include lines need to be defined via command line arguments. > > >FreeType already support
Re: [ft-devel] FreeType Amalgamation
>...I add twenty-five FreeType C files directly to the project or makefile... >...It is tedious since they are in a bunch of different folders that also >...contain other C files that should NOT be added. I have noticed this as well. The only way to figure out which .c are actually needed is to consult the project file or Makefile. >...there are several macros that would not work if all sources are >concatenated. >...An example is GET_PIC() macro defined by src/xxx/yyypic.h. and >src/xxx/ttpic.h Isn't this easily fixed by renaming one of the #define and changing the appropriate source files? >When I found them, I could not decide which is appropriate direction quickly; >giving some prefix/suffix to separate them to different namespaces, or the >insertions of "#undef GET_PIC" macros. What's wrong with #define GET_PIC and #define GET_PIC2 (for example)? At least this way the identifiers are unique and you can distinguish them in a search. >Can you use this? >http://www.cs.berkeley.edu/~necula/cil/merger.html This is a nifty program but it doesn't produce an amalgamation. In order for the resulting amalgamation to retain all of the original functionality, the C preprocessor should NOT be run on the sources. Directives need to remain intact. Well, except for certain #include lines (which cause the file to get inserted on the first occurrence). >Such an approach would make the output more difficult to edit directly >though, so it would then really only be meant to be regenerated when >changes are made to the original source. An amalgamation is never edited directly. It is always recreated from the original sources. >> 1) Some FreeType #include statements use angle brackets instead of >> double quotes. e.g. #include Why? > >This is to control inclusion with the -I command line flag of the >compiler. Think of build_dir != src_dir (which is very common on Unix >boxes). I understand the angle brackets now. It is because there are several versions of ft2build.h. If we roll them all together into a single file with appropriate preprocessor directives to decode the platform then the angle brackets would no longer be necessary, since there would only be one file. >> 2) Some FreeType #include statements use macros, like "#include >> FT_GLYPH_H". This complicates automated tools. > >I neither have time nor energy to change that. It's there since ten >years, and it works essentially everywhere. Note that there are other >packages which do similar things, for example `boost'. Sure, but it gets in the way of an amalgamation. It can be worked around though. However, what is the purpose? Is there ever a situation where FT_GLYPH_H is defined to something other than what exists in the header file? >> 3) A new ftconfig.h should be created that has a preamble for >> decoding the platform, [...] > >How shall this work? There are dozens of platforms, and you want to >hard-code them all in a configuration header file? Yes, that is the hope. This is the approach taken by boost. >Let me ask it differently: What platforms are you going to support? A >generic solution needs configuration done by an external tool >(e.g. autoconf), but this somehow contradicts your idea of simply >having everything in a large file.[1] The amalgamation should work with all platforms that FreeType currently supports, of course! Requiring autoconf also contradicts the purpose of this. It should be possible to just "drop in" the amalgamation, to an existing project, without running any separate tools. This way, when someone publishes an application that uses the FreeType amalgamation, anyone who wants to build it can just pick up the sources, open the project, and press the "build button" (figuratively) - no separate tools, dependencies, or configuration is needed. >Given the many problems, I suggest a step-by-step approach, and I hope >that you can assist, test, and develop. Yes I agree. It's good to know about GET_PIC, that would trip up the amalgamation. But it is easily fixed. The issue with the #include lines is also fixable, for example: amalgamator.exe -d FT_GLYPH_H=src/ftglyph.h ... It could be a requirement of the amalgamation tool that macros used in #include lines need to be defined via command line arguments. >FreeType already supports flat-directory compilation (see docs/INSTALL.ANY), >maybe this is a good starting point. Well nice suggestion but this doesn't get us much. I prefer a requirement of passing -l flags to the amalgamation tool to inform it of all the directories to search for includes, because this way someone who wants to produce an amalgamation does not have to re-shuffle the FreeType source tree after they check it out. >Note that David Turner developed the current macro inclusion scheme >while working on a *Windows* box more than ten years ago, so it is not >the result of sick Unix programmers :-) My target audience...well lets just say that anything I develop needs to be largely "idiot proof."
Re: [ft-devel] FreeType Amalgamation
[ If your reader did not already told you: warning, long post! ]
Vinnie wrote:
> I'm interested in building an "amalgamated" version of FreeType.
If I understand correctly your quest, Freetype 1 used to have such an
option ("single object file", a.k.a freetype.[co]); in fact it was/is
even the base option!
For Freetype 2 (b. 1999), David went away from this scheme, in my eyes
for the benefit of a much increased modularity; of course, for
"mainstream" compilations where all the stuff ends being part of a
shared library or DLL built by mostly automatic tools, there is not much
of a difference at the end; where it IS really different is for others
users of the library, particularly those who compile for embedded
targets, where the space is always a concern.
I do not know if it still useful. Voices?
> Specifically, I would like to use an in-house tool to combine all the
> FreeType headers and source files into a set consisting of a single .h and .c
> (or a couple of .c files if they are too large). This amalgamation would be
> much easier to use - instead of requiring a bulky Makefile or IDE-specific
> project file, one could just add the .c to an existing project.
Not sure I understand all the point, but it seems to me an issue at
software engineering here.
About the .c first:
In the beginning, (static) libraries where invented in order to share
code between projects; to maximize the space efficiency, the pieces in
the libraries were cut in smallest chunks; and linkers were invoked to
select only the relevant parts into the final binary. This model also
proved very good at paralleling tasks, where the libraries are developed
by some team, with a clearly defined interface, and used by several
independent programs created by different teams.
Then came dynamic linking and shared libraries, and in this view the
cutting process became essentially obsolete: all the code is present on
secondary storage (the shared object), and the selection of the
necessary pieces is done as-needed, mainly by the demand-paging
functions of the operating system through the dynamic linker.
Are you saying the Freetype project should move away from that
cutting-in-pieces process?
Or is it just about merging a big number of independently kept .c and
internal .h into one physical file (like sqlite3 is doing)?
My guess is such a work should pretty easy to do for the .c, but more
complex for the headers internal to the library; it looks like to me as
standard 4.3BSD unifdef(1), expanded to deal with #include as well;
perhaps such a tool already exist. Another possibility is a sed script
along the lines of
/^#include FT_FREETYPE_H/{
d; r path/to/already/merged/freetype/freeetype.h; }
/^#include FT_ERRORS_H/{
d; r path/to/already/merged/freetype/fterrors.h; }
/^#include FT_INTERNAL_OBJECTS_H/{
d; r path/to/already/merged/freetype/internal/ftobjs.h; }
I have no idea if there are cyclic dependencies, however...
Then, about the .h:
First, I understand that from the external point of view, it is already
looks like
#include
#include FT_FREETYPE_H
Granted, they are two files (ft2build.h is really just a proxy for
config/ftheader.h, you could substitute one for the other) not one, but
it really look like to me what you are asking for.
If the point is about the headers for the optional parts (#include
FT_BITMAP_H, FT_CACHE_H, FT_GLYPH_H, FT_TRUETYPE_IDS_H, etc.) this is
really the same point as above: if modularity is dropped, all those
files will be integrated into FT_FREETYPE_H; again very much like as it
was for Freetype 1, or as it is for or (Plan 9). An
important resulting difference here used to be compilation times --
which issue was "solved", particularly for Windows or Carbon, with
pre-compiled headers, a "feature" which is at odds with Freetype build
system... but I digress ;-)
> For my purposes, there is value in being able to distribute a project that
> uses FreeType, but has no external dependencies (i.e. someone does not need
> to visit a separate source code repository to obtain freetype).
Freetype is basically free-standing, it does not need anything beyond a
C compiler and the most standard C functions; so a full copy of Freetype
tree will fit the purpose, it is just less practical than a couple of files.
The real issue with external dependencies is about upgrading. If we have
a look over the last 10 years of Freetype history as condensed into
docs/CHANGES, most version bumps are either bugfixes for some previously
introduced changes, or vulnerabilities fixes. Both are good reasons to
upgrade as soon as possible the version of Freetype in use. Having
Freetype provided in form of a few big flat files does not change
anything to the issue, upgrading is still recommended practice.
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 wi
Re: [ft-devel] FreeType Amalgamation
>> How shall this work? There are dozens of platforms, and you want >> to hard-code them all in a configuration header file? > > I'm afraid that MacOS specific ugly hacks (detecting Mac OS, > excluding CodeWarrior, detecting Mac OS X, excluding PPC, excluding > 64bit, etc etc) made Vinnie feel sick. I don't think so :-) If I understand him correctly, he would like to configure everything with platform-dependent macros in a single header file. Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
Werner LEMBERG wrote: >> 3) A new ftconfig.h should be created that has a preamble for >> decoding the platform, [...] > > How shall this work? There are dozens of platforms, and you want to > hard-code them all in a configuration header file? I'm afraid that MacOS specific ugly hacks (detecting Mac OS, excluding CodeWarrior, detecting Mac OS X, excluding PPC, excluding 64bit, etc etc) made Vinnie feel sick. If I can say some excuse, it is because a public function heavily depending with classic Mac OS was accidentally introduced and enabled by default, and we have to keep from "unresolved symbol blah blah blah" troubles. When FreeType will make a big bump including the removal of deprecated API, the ugly hack in ftconfig.h for Mac OS will be removed. Regards, mpsuzuki ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
Werner LEMBERG wrote: >>> Can you give an example? Perhaps we can rename macros if it is not >>> too cumbersome. >> An example is GET_PIC() macro defined by src/xxx/yyypic.h. > > Aah, this is stuff written by a contributor, and which I've never had > the energy to fully integrate (including formatting) because it is > disabled by default. Apparently, only a single compiler, brew, needs > it. Oh, I'm sorry. I know this was not by you. Also I had no intention to complain to the contributor. Just I wanted to hear your comment to go right way. >> sfntpic.h defines as: >> #define GET_PIC(lib) ((sfntModulePIC*)((lib)->pic_container.sfnt)) >> ttpic.h defines as: >> #define GET_PIC(lib) ((TTModulePIC*)((lib)->pic_container.truetype)) >> >> To fix the compiler warning against the redefinition of same macro >> differently (during the compilation of concatenated source in PIC >> mode), some works are needed. > > For this particular issue I suggest a module-specific prefix. OK, I will do so. Thank you for comment. Regards, mpsuzuki ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
>>Can you give an example? Perhaps we can rename macros if it is not >>too cumbersome. > > An example is GET_PIC() macro defined by src/xxx/yyypic.h. Aah, this is stuff written by a contributor, and which I've never had the energy to fully integrate (including formatting) because it is disabled by default. Apparently, only a single compiler, brew, needs it. > sfntpic.h defines as: > #define GET_PIC(lib) ((sfntModulePIC*)((lib)->pic_container.sfnt)) > ttpic.h defines as: > #define GET_PIC(lib) ((TTModulePIC*)((lib)->pic_container.truetype)) > > To fix the compiler warning against the redefinition of same macro > differently (during the compilation of concatenated source in PIC > mode), some works are needed. For this particular issue I suggest a module-specific prefix. Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
> 1) Some FreeType #include statements use angle brackets instead of > double quotes. e.g. #include Why? This is to control inclusion with the -I command line flag of the compiler. Think of build_dir != src_dir (which is very common on Unix boxes). > 2) Some FreeType #include statements use macros, like "#include > FT_GLYPH_H". This complicates automated tools. I neither have time nor energy to change that. It's there since ten years, and it works essentially everywhere. Note that there are other packages which do similar things, for example `boost'. > 3) Depending on the platform, there might be a different ftconfig.h > and/or ftmodule.h needed (possibly other sources too) Exactly. In normal Unix builds (and today we develop on Unix boxes), this is easily controlled with the -I compiler flag. > 2) I looked at some of the macros and it seems they are all set in > internal.h. I don't see any compelling reason why it is necessary > to use a macro in the #include line. There are certainly other possibilities to do it. > I've been programming for close to 30 years now and this is the > first time I've seen a macro used this way. Note that David Turner developed the current macro inclusion scheme while working on a *Windows* box more than ten years ago, so it is not the result of sick Unix programmers :-) There were good reasons for it which you might look up in the archives. > 3) A new ftconfig.h should be created that has a preamble for > decoding the platform, [...] How shall this work? There are dozens of platforms, and you want to hard-code them all in a configuration header file? Let me ask it differently: What platforms are you going to support? A generic solution needs configuration done by an external tool (e.g. autoconf), but this somehow contradicts your idea of simply having everything in a large file.[1] > These problems could be overcome a different way, by writing a > custom script that does most of this work. [...] Not a good solution, I admit. > I prefer to be able to use a generic tool that does not need to know > about FreeType specifics. This would be ideal, of course. Given the many problems, I suggest a step-by-step approach, and I hope that you can assist, test, and develop. FreeType already supports flat-directory compilation (see docs/INSTALL.ANY), maybe this is a good starting point. Werner [1] BTW, I suggest that you have a look at the `gnulib' repository to see how many broken stuff is floating around in the world. http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=tree Just to give an example, here some documentation regarding the `sprintf' function: sprintf --- POSIX specification: http://www.opengroup.org/onlinepubs/9699919799/functions/sprintf.html Gnulib module: sprintf-posix Portability problems fixed by Gnulib: $(Q#@(B This function does not support size specifiers as in C99 (hh, ll, j, t, z) on some platforms: AIX 5.1, HP-UX 11.23, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin 1.5.24, mingw, MSVC 9, BeOS. $(Q#@(B printf of $B!F(Blong double$B!G(B numbers is unsupported on some platforms: mingw, MSVC 9, BeOS. $(Q#@(B printf "%f", "%e", "%g" of Infinity and NaN yields an incorrect result on some platforms: AIX 5.2, OSF/1 5.1, Solaris 11 2010-11, mingw, MSVC 9. $(Q#@(B This function does not support the $B!F(Ba$B!G(B and $B!F(BA$B!G(B directives on some platforms: glibc-2.3.6, MacOS X 10.5, NetBSD 5.0, OpenBSD 4.0, AIX 5.2, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9, BeOS. $(Q#@(B This function does not support the $B!F(BF$B!G(B directive on some platforms: NetBSD 3.0, AIX 5.1, HP-UX 11.23, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin 1.5.x, mingw, MSVC 9, BeOS. $(Q#@(B This function does not support the $B!F(Bn$B!G(B directive on some platforms: MSVC 9. $(Q#@(B This function does not support the $B!F(Bls$B!G(B directive on some platforms: OpenBSD 4.0, IRIX 6.5, Solaris 2.6, Cygwin 1.5.x, Haiku. $(Q#@(B This function does not support precisions in the $B!F(Bls$B!G(B directive correctly on some platforms: Solaris 11 2010-11. $(Q#@(B This function does not support format directives that access arguments in an arbitrary order, such as "%2$s", on some platforms: NetBSD 3.0, mingw, MSVC 9, BeOS. $(Q#@(B This function doesn$B!G(Bt support the $B!G(B flag on some platforms: NetBSD 3.0, Cygwin 1.5.24, mingw, MSVC 9. $(Q#@(B This function behaves incorrectly when a $B!F(B-$B!G(B flag and a negative width are specified together, on some platforms: HP-UX 10.20. $(Q#@(B printf "%010f" of NaN and Infinity yields an incorrect result (padded with zeroes) on some platforms: MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, AIX 5.2, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9. $(Q#@(B This function does not support preci
Re: [ft-devel] FreeType Amalgamation
2012/1/19 : > However, the source structure of FreeType2 is related with > the modularization of each features and binary compatibilities, > so the official support of the concatenated C source can be > slightly difficult (sorry!). Can you use this? http://www.cs.berkeley.edu/~necula/cil/merger.html I have no experience with it. I'm not sure what happens with macros: it may just inline them by calling the C preprocessor first. Such an approach would make the output more difficult to edit directly though, so it would then really only be meant to be regenerated when changes are made to the original source. ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
On Fri, 20 Jan 2012 06:04:04 +0100 (CET) Werner LEMBERG wrote: >> BTW, during the overhaul of PIC mode building, I found there are >> several macros that would not work if all sources are concatenated. >> Werner, should we care the inter-module namespace separation of cpp >> macros? > >This is OK with me. > >> At present, we care only the intra-module namespace separation. The >> easiest way would be the insertion of "#undef" to unsafe macros... > >Can you give an example? Perhaps we can rename macros if it is not >too cumbersome. An example is GET_PIC() macro defined by src/xxx/yyypic.h. sfntpic.h defines as: #define GET_PIC(lib) ((sfntModulePIC*)((lib)->pic_container.sfnt)) ttpic.h defines as: #define GET_PIC(lib) ((TTModulePIC*)((lib)->pic_container.truetype)) To fix the compiler warning against the redefinition of same macro differently (during the compilation of concatenated source in PIC mode), some works are needed. When I found them, I could not decide which is appropriate direction quickly; giving some prefix/suffix to separate them to different namespaces, or the insertions of "#undef GET_PIC" macros. Apparently the warning that I was afraid of won't occur in the standard building, so I could not decide it quickly... Regards, mpsuzuki ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
> However, the source structure of FreeType2 is related with the > modularization of each features and binary compatibilities, so the > official support of the concatenated C source can be slightly > difficult (sorry!). It's fine with me to improve that. > BTW, during the overhaul of PIC mode building, I found there are > several macros that would not work if all sources are concatenated. > Werner, should we care the inter-module namespace separation of cpp > macros? This is OK with me. > At present, we care only the intra-module namespace separation. The > easiest way would be the insertion of "#undef" to unsafe macros... Can you give an example? Perhaps we can rename macros if it is not too cumbersome. Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
I have no objection to the statement "compiling single C source to single object is much easier than compiling much single file is easier than compiling multiple C sources to single library", and I have to accept that many newbies had a difficulty to understand the process how to build libfreetype. Also using single object file would be much easier to use FreeType2 for a statically linked application or systems. However, the source structure of FreeType2 is related with the modularization of each features and binary compatibilities, so the official support of the concatenated C source can be slightly difficult (sorry!). BTW, during the overhaul of PIC mode building, I found there are several macros that would not work if all sources are concatenated. Werner, should we care the inter-module namespace separation of cpp macros? At present, we care only the intra-module namespace separation. The easiest way would be the insertion of "#undef" to unsafe macros... Regards, mpsuzuki On Thu, 19 Jan 2012 12:05:55 -0800 "Tom Bishop, Wenlin Institute" wrote: > >On Jan 19, 2012, at 8:32 AM, Vinnie wrote: > >> I'm interested in building an "amalgamated" version of FreeType. > >I would love to be able to use that. Currently I don't build FreeType >as a library, I add twenty-five FreeType C files directly to the >project or makefile in which they are used. (For cross-platform >development, I find this is easier than building libraries.) It is >tedious since they are in a bunch of different folders that also >contain other C files that should NOT be added. A single C file would >be much more convenient. > >Tom > >文林 Wenlin Institute, Inc.Software for Learning Chinese >E-mail: [email protected] Web: http://www.wenlin.com >Telephone: 1-877-4-WENLIN (1-877-493-6546) >___ > > > > > > >___ >Freetype-devel mailing list >[email protected] >https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
On Jan 19, 2012, at 8:32 AM, Vinnie wrote: > I'm interested in building an "amalgamated" version of FreeType. I would love to be able to use that. Currently I don't build FreeType as a library, I add twenty-five FreeType C files directly to the project or makefile in which they are used. (For cross-platform development, I find this is easier than building libraries.) It is tedious since they are in a bunch of different folders that also contain other C files that should NOT be added. A single C file would be much more convenient. Tom 文林 Wenlin Institute, Inc.Software for Learning Chinese E-mail: [email protected] Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
On Jan 19, 2012, at 8:32 AM, Vinnie wrote: > I'm interested in building an "amalgamated" version of FreeType. I would love to be able to use that. Currently I don't build FreeType as a library, I add twenty-five FreeType C files directly to the project or makefile in which they are used. (For cross-platform development, I find this is easier than building libraries.) It is tedious since they are in a bunch of different folders that also contain other C files that should NOT be added. A single C file would be much more convenient. Tom 文林 Wenlin Institute, Inc.Software for Learning Chinese E-mail: [email protected] Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType Amalgamation
I'm interested in building an "amalgamated" version of FreeType. Specifically, I would like to use an in-house tool to combine all the FreeType headers and source files into a set consisting of a single .h and .c (or a couple of .c files if they are too large). This amalgamation would be much easier to use - instead of requiring a bulky Makefile or IDE-specific project file, one could just add the .c to an existing project. For my purposes, there is value in being able to distribute a project that uses FreeType, but has no external dependencies (i.e. someone does not need to visit a separate source code repository to obtain freetype). True, this could be done by creating a deep clone of the entire FreeType source tree but this is a bulky solution. As FreeType is a very mature project that is now quite stable and not undergoing much change, providing an amalgamated format seems useful. There are some other open source products that exist in amalgamated form. For example, sqlite: http://www.sqlite.org/amalgamation.html And Juce: http://code.google.com/p/dspfilterscpp/source/browse/#svn%2Ftrunk%2Fshared%2FJuceAmalgam Unfortunately, creating an amalgamated version of FreeType would require some changes to the way that source files are organized. Three issues come up: 1) Some FreeType #include statements use angle brackets instead of double quotes. e.g. #include Why? 2) Some FreeType #include statements use macros, like "#include FT_GLYPH_H". This complicates automated tools. 3) Depending on the platform, there might be a different ftconfig.h and/or ftmodule.h needed (possibly other sources too) My comments: 2) I looked at some of the macros and it seems they are all set in internal.h. I don't see any compelling reason why it is necessary to use a macro in the #include line. I've been programming for close to 30 years now and this is the first time I've seen a macro used this way. 3) A new ftconfig.h should be created that has a preamble for decoding the platform, and all of the separate ftconfig.h / ftmodule.h rolled into a single .h that uses preprocessor definitions to select the appropriate set of code. Alternatively, the platform specific header files can be given unique names (e.g. ftmac_config.h, ftmac_module.h) and then get conditionally included. Like this: #if FT_PLATFORM_MAC #include "ftmac_config.h" #else #include "ftgeneric_config.h" #endif These problems could be overcome a different way, by writing a custom script that does most of this work. This script would be fairly hefty to work around these issues and would be quite FreeType-specific. It would also need maintenance and testing every time FreeType changed. The resulting amalgamation would likely only work on one platform - it would be necessary to have a different amalgamation for each platform the way the source files are structured now (with some platforms having their own ftconfig.h / ftmodule.h). Because of this, I have little to no motivation to write such a customized script, I prefer to be able to use a generic tool that does not need to know about FreeType specifics. What is the level of desire for bringing about these changes? Thanks! ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
