> Here is an updated (probably final at this point) case study.
Good work! I like it.
Some remarks.
. Please stay in the 78 column width limit. At least one
C preprocessor doesn't like
#define FOO( bar, \
baz ) ...
but this is a bug in this program, so we don't care.
. I don't like having macros with parameters looking like a function
which can't be closed with a semicolon. This is error prone. I
always want this:
FT_FOO(bar);
So please add proper
while ( 0 ) do { <macro body> }
constructs where necessary.
. If possible, prepare a set of patches, together with proper
ChangeLog entries, which builds up your modifications step by
step. This greatly simplifies understanding your changes. Note,
however, that I don't want to force you to artificially reduce the
size of the patches. The diffs should be rather logical than
small.
. Is it possible (and useful) to move the large code chunk which
modifies ftinit.c to ftpic.c?
BTW, somewhere in the diff there is a typo `defualt'...
> However, I can't figure out how to get there from the various
> functions inside a module :( As you can see, autofit still stuffs
> its own data into FT_LibraryRec, but this isn't very good. Help?
Not yet, sorry. I have a lot of other things to do.
> in ftrend1.c there appears to be a hack that checks a pointer
> directly (instead of having two different functions for two
> different classes). I had to modify it to another hack (check the
> number in the module's name.
Can you prepare a patch which fixes this issue? This seems to be
unrelated to your PIC changes.
> 3) So far I have converted the basic module/renderer/driver interface,
> and most of the autofit module.
> I am not familiar with the insides of FT2, so can you sort of
> guesstimate how much of the conversion work I already did? 1%? 2% ?
> 5%? 10%? 20%?
Even more, I think. Normally, the function tables which you have to
modify are located at the end of a FreeType source code file, so you
can look it up by yourself.
> Is there a particular nasty case you can think of? Some module that
> uses a lost of function pointers or complex structs with a lot of
> interdependent pointers? (sfnt/sfdriver.c seems to contain a large
> function table, for example).
Hopefully not, since such dependencies would be against FreeType's
modularity and should be resolved in advance.
Do you have the possibility to work directly with the CVS code? The
main advantage would be that you could provide small patches right now
which fixes inconsistencies of FreeType independently of your PIC
changes.
Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
