> From: Alexei Podtelezhnikov <apodt...@gmail.com> >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 Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel