Re: [ft-devel] FreeType patches to support amalgamation

[Vinnie]

> From: Alexei Podtelezhnikov <address@hidden>
>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.