Re: [ft-devel] FreeType patches to support amalgamation
Yes. So far there are 6 sets of changes, using the naming conventions that you recommended. These patches were created off an unmodified copy of the publicly available FreeType 2.4.8. Unfortunately I'm using SVN but the patches should still be applicable (?) Thanks for the patches! I've committed them, with slight modifications. The next time please take care of the whitespace formatting, and please follow the structure of the ChangeLog entries more closely. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation #2
One more minor set of changes, I moved an inline comment to the previous line on a couple of #include lines. What is this change set good for, except cosmetics? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Hi, For first, I state that I have no objection against the decision by Werner, because now the time he spends for the maintenance of FreeType2 (in official branch) is longer than those of other FreeType2 developers (maybe except of David Turner). But, if I just talk about the idea to change program source files, to prevent the conflict of the name of types, functions, and variables, I feel a sympathy with Alexei. Also some temporal macro functions must be cared. Putting the prefix or postfix to all names, we can avoid the conflicts, but it makes the names longer, and it makes the sources eye-unfriendly (especially for the die-hard VT100 emulator users like me). It is good idea to consider the conflict of inter-source names from the beginning of a software design, but, changing the existing source files designed without inter-source name conflict is painful work. # there are some macros that are just designed to reduce # the length of a line, something like, # #define GET_A_PLACE_IN_CA( a ) ( earth-america-north_america-usa-california-a ) I wish if there is some program to convert a group of source files to conflict-free source files by inserting the prefix/postfixes. If there is such, all developers who are asked to support the concatenated source can reduce their efforts. I'm unfamiliar with C source parsers that can pickup the names and filter them correctly (if anybody knows, please let me know!), so I could not propose another option to support Vinnie's request, thus, I must follow the decision by Werner. Regards, mpsuzuki Werner LEMBERG wrote: How about a shared header file if those modules share a structure? Don't you see that this patch set is just a pile of pure stinking crap??? Alexei, your comments are at the border of insults. Please don't do that! We already know that you don't like the patches. It doesn't help at all if you repeat this again and again. You have always the possibility to maintain a branch without these patches applied. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Alan Coopersmith wrote: Using anything but a shared library for FreeType just seems to be begging for pain [...] Unlike many high-profile packages, Freetype is also used on (mostly embedded) platforms where shared libraries just do not exist. Also if some vendor has a design which, perhaps for historic reasons, do not include shared libraries, to make a single exception for Freetype will not ease substantially her updating pain. And forcing a design change to use shared libraries all over the place is often an order of magnitude more complex (and more expensive.) Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Putting the prefix or postfix to all names, we can avoid the conflicts, but it makes the names longer, and it makes the sources eye-unfriendly (especially for the die-hard VT100 emulator users like me). I usually strictly enforce a 78 character per line limit, so I also want to avoid overly long identifiers. Fortunately, the suggested changes from Vinnie are non-intrusive IMHO and surprisingly minor. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
How about a shared header file if those modules share a structure? Don't you see that this patch set is just a pile of pure stinking crap??? On Tue, Feb 21, 2012 at 9:56 AM, Vinnie thev...@yahoo.com wrote: Werner: 2012-02-20 Vinnie Falco vinnie.fa...@gmail.com ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, TRaster ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Unless I've misunderstood, It seems to me that the changes being made are not to amalgamate FreeType into a couple of files, but just to rename some stuff/change some #defines to make this possible for another tool to optionally do. If so, I really can't see what the problem is and why you're being offensive on the mailing list - it just makes FreeType usable in a different way for those who would like it, doesn't it? As for your earlier comment: You will make people who borrow from FreeType miserable and make them curse at you for renaming stuff for no good reason whatsoever. I can't speak for anyone else, but FreeType has been a fantastic and much-appreciated library over the years for us and we have total respect for the people who have put so much time into creating it, so if a bunch of stuff gets renamed that makes it easier to use for others to benefit from then it's fine with us. On 21 Feb 2012, at 17:12, Alexei Podtelezhnikov wrote: How about a shared header file if those modules share a structure? Don't you see that this patch set is just a pile of pure stinking crap??? On Tue, Feb 21, 2012 at 9:56 AM, Vinnie thev...@yahoo.com wrote: Werner: 2012-02-20 Vinnie Falco vinnie.fa...@gmail.com ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, TRaster ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Date: Tue, 21 Feb 2012 08:02:43 -0500 From: Alexei Podtelezhnikov apodt...@gmail.com You planing this for Stone Age people who do not know how to use make. I rest my case. Actually, that is true. My target audience includes musicians or artists who are beginning to dabble in C / C++ programming. The are predominantly using XCode on Mac OS X, with the remainder on Windows with a free copy of Visual Studio Express. The bulk of these users do not know how to use Make, and can't be bothered to download additional dependencies (like visiting the FreeType home page, extracting the sources, and performing a build). My open source offerings have to come in a single archive - if I require that they use SVN or GIT to retrieve the sources, a non trivial percentage of visitors will be unable or unwilling to perform the extra steps required. Usage of FreeType for this scenario follows a very predictable pattern: the user wants to try their hand at writing a VST audio plugin, desires a cool looking interface that mimics some analog device (examples: http://www.midictrl.com/midictrl_new.jpg, http://i49.tinypic.com/120o7j5.jpg), and then wants their embedded fonts to look good at small point sizes. With an amalgamated version of FreeType I can add support for hinted fonts to my open source offerings, while including the entire FreeType distribution as a single source file instead of a large tree. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Vinnie thev...@yahoo.com wrote: With an amalgamated version of FreeType I can add support for hinted fonts to my open source offerings, while including the entire FreeType distribution as a single source file instead of a large tree. How about providing a single precompiled library file for these people? -- Dmitry. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On 02/21/12 05:02 AM, Alexei Podtelezhnikov wrote: All this work is from Stone Age, when noone shared and everyone only used a single file and a single command to build something. Using anything but a shared library for FreeType just seems to be begging for pain everytime FreeType has to issue a security fix or other critical fix, and suddenly you need to redeliver every single application with the FreeType code embedded, instead of one common update to a shared library. But then I suppose I've been in the Unix/Linux world for far too long, which provides for this nicely, unlike the horror stories we hear from other platforms (like those in which you need to deliver via an app store or similar installer everything your software needs that isn't part of the core OS). -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Vinnie thev...@yahoo.com wrote: How about providing a single precompiled library file for these people? That would only work for one particular build environment, and within that environment, only one target. For example, debug, or release. Or 32 bit versus 64 bit. If the resulting FreeType library were misused, the absence of sources would complicate debugging. That's true that compiling something slightly more complex than Hello World! requires some efforts. -- Dmitry. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On Tue, Feb 21, 2012 at 10:44 AM, Vinnie thev...@yahoo.com wrote: Date: Tue, 21 Feb 2012 08:02:43 -0500 From: Alexei Podtelezhnikov apodt...@gmail.com You planing this for Stone Age people who do not know how to use make. I rest my case. Actually, that is true. My target audience includes musicians or artists who are beginning to dabble in C / C++ programming. The are predominantly using XCode on Mac OS X, with the remainder on Windows with a free copy of Visual Studio Express. It is hard to believe that there are people who'll dive into font rendering without first learning how to use multiple files and libraries in a project. It is easier to teach them about libraries anyway. Freetype is available on MacOS as a library. Why not use it? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On Tue, Feb 21, 2012 at 11:03 AM, Chris Morgan chmor...@gmail.com wrote: Hey. This kind of response isn't cool man. If Vinnie's patches disambiguate and otherwise clarify the code then they are good changes, even if it enables him to do things that we find odd. There is nothing ambiguous in FreeType code. Everything is nicely organized in subdirectories. Whoever dumps it all in a single file should deal with the consequences. It is never a FreeType problem and FreeType should not bother. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
From: Alexei Podtelezhnikov apodt...@gmail.com Sent: Tuesday, February 21, 2012 8:28 AM It is hard to believe that there are people who'll dive into font rendering without first learning how to use multiple files and libraries in a project. I agree, it is hard to believe but that's just how it is. For some reason, implementing a synthesizer or sampler audio plugin has tremendous appeal for non-programmers. I have no explanation but if you want to witness this phenomenon yourself, please visit these heavily trafficked pages: README - For non-programmers with great ideas http://www.kvraudio.com/forum/viewtopic.php?t=194452 How Do I Create VST Plugins? Information for those just getting started http://www.kvraudio.com/forum/viewtopic.php?t=329696 What are the most important parts of C++ for coding plug-ins? http://www.kvraudio.com/forum/viewtopic.php?t=52342 It is easier to teach them about libraries anyway. But even easier to provide a single compressed archive containing sources with no external dependencies, and a project file for each supported build environment which can be opened and built without any additional steps. Freetype is available on MacOS as a library. Why not use it? FreeType is not available under Windows. Sure I could add some scaffolding to allow the GNU/Linux/X Windows and Mac OS X projects to use the built-in operating system provided FreeType, but this creates new problems. What if the version of FreeType on the user's system is different? Furthermore it would be necessary to add some conditional compilation to detect the build environment, and now we have source code that starts to diverge across platforms. Carrying this to its logical conclusion and we would have .mk files, a CONFIGURE script, the necessity for additional build tools, etc... On the other hand I could just include the FreeType sources or amalgamation with my open source project and ignore the system provided headers and library. This bypasses all of the problems previously mentioned, and has the benefit that compilation and execution becomes completely predictable. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On Tue, Feb 21, 2012 at 11:54 AM, Vinnie thev...@yahoo.com wrote: From: Alexei Podtelezhnikov apodt...@gmail.com Sent: Tuesday, February 21, 2012 8:28 AM It is hard to believe that there are people who'll dive into font rendering without first learning how to use multiple files and libraries in a project. I agree, it is hard to believe but that's just how it is. For some reason, implementing a synthesizer or sampler audio plugin has tremendous appeal for non-programmers. So you want to encouraging bad programming practices. That is fine. I am only against FreeType helping you teach children BAD things.. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
To be honest, I am perplexed by this amalgamation exercise. All of this apparently needed because some obscure in-house tool does not know how to resolve the name conflicts. Teach the damn tool how to resolve the name conflicts by adding prefixes or suffixes! Why do you butcher perfectly legal code C-code? You problem is in the tool - not it in FreeType. On Mon, Feb 20, 2012 at 1:13 PM, Vinnie thev...@yahoo.com wrote: From: Werner LEMBERG w...@gnu.org Subject: Re: [ft-devel] FreeType Amalgamation Indeed. Can you provide patches, splitting the discussed issues into logical change sets so that I can easily add them to the git repository? Yes. So far there are 6 sets of changes, using the naming conventions that you recommended. These patches were created off an unmodified copy of the publicly available FreeType 2.4.8. Unfortunately I'm using SVN but the patches should still be applicable (?) The patches are numbered according to the change log entry: 2012-02-20 Vinnie Falco vinnie.fa...@gmail.com [1] ftgrays.c, ftraster.c: Rename TBand* [2] ftgrays.c, ftraster:c: Undefined FLOOR, CEILING, TRUNC, SCALED [3] ftgrays.c, ftraster.c: Rename [T,P]Worker* [4] ftgrays.c, ftraster.c: Rename RAS_ARG* and [P,T]Raster [5] fterrors.h: Conditionally undefine FT_KEEP_ERR_PREFIX tterrors.h: Undefine FT_ERR_PREFIX [6] ttdriver.c, cffdriver.c: Rename Load_Glyph t1cmap.c, t1driver.c: Rename t1_get_glyph_name cidload.c: Rename t1_init_loader, t1_done_loader cidload.c, t1load.c: Rename parse_font_matrix I need to work on the amalgamation tool a little more to support inclusion of fterrdef.h multiple times, and then do some testing. Thanks, Vinnie ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
You again manage to present this as a legitimate goal :) It is your tool that breaks the code :) You are not fooling me here. Again, I'll say that this is just such a bizarre objective that you HAVE TO justify this and tell which platform on Earth needs it. Remember it has to be a platform which does not support shared or static libraries or Makefiles. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
To be honest, I am perplexed by this amalgamation exercise. All of this apparently needed because some obscure in-house tool does not know how to resolve the name conflicts. I don't think so. Teach the damn tool how to resolve the name conflicts by adding prefixes or suffixes! ... Please stay polite. You problem is in the tool - not it in FreeType. What Vinnie has provided is a good compromise, and I have requested him to do so. It will take some time until I've integrated this, however. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Again, I'll say that this is just such a bizarre objective that you HAVE TO justify this and tell which platform on Earth needs it. ??? It's not related to a specific platform at all. It's a matter of an easy way to distribute the FreeType code with a very few number of files. Remember it has to be a platform which does not support shared or static libraries or Makefiles. Please reread the thread about amalgamation. You are apparently mixing up the issue with something else. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On Mon, Feb 20, 2012 at 5:45 PM, Werner LEMBERG w...@gnu.org wrote: Again, I'll say that this is just such a bizarre objective that you HAVE TO justify this and tell which platform on Earth needs it. ??? It's not related to a specific platform at all. It's a matter of an easy way to distribute the FreeType code with a very few number of files. Easier to distribute? Distribute for what? Is there any other project that bought into this nonsense? All I see is just an exercise in futility. This efforts should be devoted for something more worthy. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
