Re: [ft-devel] FreeType patches to support amalgamation #2
> The amalgamation tool does not understand C style comments so it > gets confused when they appear on an #include line. Hmm. Such a tool should be able to handly any valid C (or C++) code... > I guess I could add support for it but that will only make the tool > more complex and increase the work to port it another language. Well, I strongly suggest that you add support for it. Werner ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation #2
>Date: Fri, 24 Feb 2012 12:29:13 +0100 (CET) >From: Werner LEMBERG >Subject: 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? The amalgamation tool does not understand C style comments so it gets confused when they appear on an #include line. I guess I could add support for it but that will only make the tool more complex and increase the work to port it another language. ___ Freetype-devel mailing list [email protected] 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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 [email protected] 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 [email protected] 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 [email protected] 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 > [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 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. Exactly. No need to further discuss that. I've accepted Vinnie's implementation route, and I'm going to incorporate his patches. Werner ___ Freetype-devel mailing list [email protected] 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??? 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 [email protected] 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 wrote: > > >> From: Alexei Podtelezhnikov >> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
> From: Alexei Podtelezhnikov > 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 [email protected] 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 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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On Tue, Feb 21, 2012 at 12:07 PM, Dmitry Timoshkov wrote: > Vinnie 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. > Even "Hello World!" usually uses msvcrt.dll or whatever. ___ Freetype-devel mailing list [email protected] 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 wrote: >> Date: Tue, 21 Feb 2012 08:02:43 -0500 > >> From: Alexei Podtelezhnikov >> >> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
> From: Alan Coopersmith > > 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. This is true in the general case, and specific to applications which allow a font to be chosen by the user or programmatically but almost always false where the use-case is a statically linked FreeType in conjunction with fonts embedded in the host application and not changable by the user. ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Vinnie 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 [email protected] 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- [email protected] Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On Tue, Feb 21, 2012 at 11:01 AM, Vinnie wrote:
>> From: Dmitry Timoshkov
>
>> Sent: Tuesday, February 21, 2012 8:53 AM
>>
>>> 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?
>
> 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. One could simply include the full FreeType
> source tree but then we are back where we started. Keep in mind, I try to
> target most popular platforms (Windows, Mac OS, iOS, Android, GNU/Linux
> with X Windows) by using a cross platform library ("Juce").
>
> I'm sensing a lot of friction with producing an amalgamated distribution of
> FreeType. Perhaps this comment will sweeten the pot:
>
> From http://www.sqlite.org/amalgamation.html
> "In addition to making SQLite easier to incorporate into other
> projects,
> the amalgamation also makes it run faster. Many
> compilers are able to
> do additional optimizations on code when
> it is contained with in a single
> translation unit such as it
> is in the amalgamation. We have measured
> performance improvements
> of between 5 and 10% when we use the
> amalgamation to compile
> SQLite rather than individual source files.
> The downside of this
> is that the additional optimizations often take the
> form of
> function inlining which tends to make the size of the resulting
> binary image larger."
>
>From experience the amalgamated sqlite is a bit of a pain since the
project doesn't seem to support a non-amalgamated build and it was a
pain including the c headers into some c++ code. I've got a bit more
experience integrating legacy c projects with c++ now so maybe it
would be easier for me but I think I couldn't use the amalgamated
approach because there are lots of sqlite structs/types that aren't
c++ compliant.
In any case, modern compilers can do whole program optimization and
its only 5 or 10% performance improvement. You'd have to create a
benchmark and test the two types of builds with a modern compiler in
order to start to collect the data to make the same argument with
freetype.
Chris
___
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
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. If there are common structures that should be used then that is valid feedback, please clarify which ones etc and where he is copying structures that were previously or could/should be shared. Keep this a technical discussion, its just code and Werner isn't going to be checking in changes that screw the code up. Chris On Tue, Feb 21, 2012 at 10:12 AM, 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 wrote: >> Werner: >> >> 2012-02-20 Vinnie Falco >> >> >> ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, >> TRaster >> > > ___ > 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 patches to support amalgamation
> From: Dmitry Timoshkov
> Sent: Tuesday, February 21, 2012 8:53 AM
>
>> 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?
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. One could simply include the full FreeType
source tree but then we are back where we started. Keep in mind, I try to
target most popular platforms (Windows, Mac OS, iOS, Android, GNU/Linux
with X Windows) by using a cross platform library ("Juce").
I'm sensing a lot of friction with producing an amalgamated distribution of
FreeType. Perhaps this comment will sweeten the pot:
>From http://www.sqlite.org/amalgamation.html
"In addition to making SQLite easier to incorporate into other
projects,
the amalgamation also makes it run faster. Many
compilers are able to
do additional optimizations on code when
it is contained with in a single
translation unit such as it
is in the amalgamation. We have measured
performance improvements
of between 5 and 10% when we use the
amalgamation to compile
SQLite rather than individual source files.
The downside of this
is that the additional optimizations often take the
form of
function inlining which tends to make the size of the resulting
binary image larger."
___
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Vinnie 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 [email protected] 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 > > 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 [email protected] 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 wrote: >> Werner: >> >> 2012-02-20 Vinnie Falco >> >> >> ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, >> TRaster >> > > ___ > 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 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 wrote: > Werner: > > 2012-02-20 Vinnie Falco > > > ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, > TRaster > ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Werner: 2012-02-20 Vinnie Falco ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, TRaster Attached is the change you requested to undefined the RAS_* macros. Thanks, Vinnie 4.patch Description: Binary data ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
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. I tend to agree, I somehow doubt that there is a single project out there that would even consider accepting this kind of patches. -- Dmitry. ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
All this work is from Stone Age, when noone shared and everyone only used a single file and a single command to build something. You will make people who borrow from FreeType miserable and make them curse at you for renaming stuff for no good reason whatsoever. Yes, taking smooth out of FreeType for rasterizing shapes used to be easy. O those progressive code sharers... Screw them! You planing this for Stone Age people who do not know how to use make. I rest my case. ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
On Tue, Feb 21, 2012 at 4:11 AM, Antoine Leca wrote: > Alexei Podtelezhnikov wrote: >> Why do you butcher perfectly legal code C-code? >> You problem is in the tool - not it in FreeType. > This is not fair. The exercise do show some areas in Freetype which code > will be clearly made better after the corrections proposed by Vinnie. > Examples are the #undef pp-instructions before #define (patches #2, or > #5 2nd part); or the correction in cidload.c of the local methods > t1_init_loader (resp. t1_free_loader) by cid_init_loader (resp. > cid_free_loader) (patch #6.) > > I also second Werner thinking this will need a fair amount of editor > work, hence time, to be digested. Sure. Some parts of it are Ok. Smooth and raster share code naturally. The whole idea of of dumping them in a singe file without thinking goes against fundamentals of code sharing philosophy. It just makes me barf no matter how you change the names. They are meant to be separate modules. And when I make a change in one I'd like to be able to share code by to copy-pasting it. ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Alexei Podtelezhnikov wrote: > Why do you butcher perfectly legal code C-code? > You problem is in the tool - not it in FreeType. This is not fair. The exercise do show some areas in Freetype which code will be clearly made better after the corrections proposed by Vinnie. Examples are the #undef pp-instructions before #define (patches #2, or #5 2nd part); or the correction in cidload.c of the local methods t1_init_loader (resp. t1_free_loader) by cid_init_loader (resp. cid_free_loader) (patch #6.) I also second Werner thinking this will need a fair amount of editor work, hence time, to be digested. Antoine ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Hello Vinnie! Thanks a lot for your work. I only have a single comment; everything else looks fine. In file `4.patch': > -#define RAS_ARGS /* void */ > -#define RAS_ARG/* void */ > +#define black_RAS_ARGS /* void */ > +#define black_RAS_ARG/* void */ > > -#define RAS_VARS /* void */ > -#define RAS_VAR/* void */ > +#define black_RAS_VARS /* void */ > +#define black_RAS_VAR/* void */ I think this is a bad change since it unnecessarily uglifies the source. It should be fully sufficient to have #undef RAS_ARGS #undef RAS_ARG #undef RAS_VARS #undef RAS_VAR #define RAS_ARGS black_PWorker worker, #define RAS_ARG black_PWorker worker #define RAS_VARS worker, #define RAS_VAR worker (and similar code for `gray') as you've done elsewhere too. Am I missing something? Otherwise please redo this patch. Werner ___ Freetype-devel mailing list [email protected] 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 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
> From: Alexei Podtelezhnikov
>Sent: Monday, February 20, 2012 12:15 PM
>Subject: 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!
>...
>You problem is in the tool - not it in FreeType.
Making cosmetic changes to identifier names in the
original source code is a simple and realistic solution. The
tool I wrote knows nothing of C syntax and does not parse
identifiers. It only recognizes #include preprocessor directives.
Building an amalgamation tool which can more fully parse
C/C++ code and extract identifiers is a non trivial exercise.
I greatly doubt my chances of success at attempting this.
Once I have achieved success in producing a working
amalgamation, it is certainly true that my home-brew tool
can be replaced by a perl script or whatever GNU/Linux
build chain tool is most appropriate and convenient
for FreeType maintainers - I certainly have no emotional
attachment but since I am doing the bulk of development on
a Windows desktop, I lean strongly towards command line
executables over shell scripts.
>Why do you butcher perfectly legal code C-code?
Two source files a.c and b.c can be "perfectly legal
C-code" but the result of concatenating them together into a
third source file may not be legal C. For example:
a.c:
static void foo() { }
b.c:
static void foo() { }
While each file is legal C code on its own, the resulting
concatenation is not:
cat a.c b.c:
static void foo() { } /* okay */
static void foo() { } /* ERROR: duplicate symbol */
I hope this addresses all the original sources of perplexity.
___
Freetype-devel mailing list
[email protected]
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 wrote: >>From: Werner LEMBERG >>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 > [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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/freetype-devel > -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
