Hi Moazin,
> I want to inquire about how FreeType devs, whenever they are fixing a bug or
> adding a new feature, code and test the new additions?
I think everyone has their own way of approaching it, just quickly highlighting
my approach and, TLDR; your approach pretty much sums it up IMO -- it can just
be optimised a bit.
> I have the following approach in mind:
>
> - Code the new stuff in the repo
> - Write a program (with a `main' function) that will eventually trigger the
> "newly added" part somehow.
> - Use GDB to set a break point on the "newly added" part and then step through
> it and confirm whether everything works or not.
> - Repeat
>
> This approach feels slow because for each new modification, the library as
> well as the program that uses it will have to be rebuilt. Is this the right
> approach? Is there a better one? Please let me know.
As for ideas:
- Build automation via a simple shell script is HIGHLY advisable; have a
script that builds the library, builds your main program, links the lot, and
also starts `gdb' with the desired settings and the desired input. If that
script is then somewhat customisable (e.g. define main features via simple
variables), you're pretty well off :)
- To speed up the build process of the library, spec. when only a few files
are changed, look into `ccache'; it's hella crazy and should speed up
your rebuild of FreeType dramatically :)
Best
Armin
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
