Re: [ft-devel] Searching for an FT2 tester program

[Werner LEMBERG]

> I've done the patches for the non pic-related changes I've made on a
> local git clone.
>
> We can try submitting (push / pull) them just to make sure I'm on the
> right track (technically), sine I'm new to git.

I assume that you have created a branch for your local changes.  You
now have to rebase your branch to the master tree so that your changes
apply smoothly.  The corresponding command is `git rebase'.

After this, use `git format-patch' to convert your commits to
patches.  That's it.  The git suite comes with good documentation
which explains the involved commands very well.

> Also I'm not sure I understand which macros you referred as
> `end-hacker macros' which you wanted me to document, please list the
> places (files) you want me to document.

Mhmm.  I'm unsure, too.  Just imagine that I want to write a new
service (or, not so likely, a new font driver).  What macros do I have
to use?  What should I take care of?

A minor technical detail: Are you sure that, say, MSVC supports up to
30 arguments for a single macro as used in FT_DEFINE_DRIVER?

> I imagine each separate commit should leave the code compiling (and
> running, at least for the non-pic mode), meaning I must not commit
> some file if a macro it uses is still not commited.

No, this is not necessary.  Just mention in the patches [1/n], [2/n],
..., that it will not compile until patch [n/n] has been applied (or
something like that).

So please select a logical order for the patches to make it easily
comprehensible.

> Also I you can have a second look at what I did in ftstroke.c,
> relating to the use of:
> extern const FT_Glyph_Class  ft_outline_glyph_class;
> And tell me if you can suggest a better solution?

Looks OK to me -- but perhaps *here* you can add some documentation
why this change is necessary, and how other parts of the code should
use it.


    Werner