Re: [ft-devel] ft2build.h being regenerated each time.

[Samuel Williams]

On 25 April 2013 19:13, Antoine Leca <address@hidden> wrote:

Samuel Williams wrote:
>> however other tasks (like hacking with Freetype being one
>> subcomponent which happens to be hacked on; or having Freetype being
>> build by various toolchains) might plainly break if you do that.
>

> Can you give a use-case of this point?

Project with various targets and several sub-packages, one of them being
Freetype; Freetype built differently for some targets.
Furthermore, the computation of dependencies is slightly broken for
another sub-project, for example because it does not take into account
the special form of Freetype internal #includes.

This almost exactly describes my project structure.

Freetype is the only project I've ever encountered that requires such an elaborate setup regarding headers, and yet it isn't the only project required to run on lots of different platforms.

So you are basically saying, you have another sub-project which has the following:

subproject.cpp:

#include <ft2build.h>

#include FT_FREETYPE_H

 

Let's assume dependency analysis can't get through the macro include FT_FREETYPE_H, so what you are suggesting essentially is that if any file in the Freetype project changes, ft2build.h should change too? Then, that file will be rebuilt.

Is this what you are suggesting?

> If you are hacking on a sub-component, clearly something must change and
> thus can be tracked using the dependency tree.

Again, you are assuming the rest of the world is perfect here.
This was my whole point: by default, the project gave up a bit of
optimisation in order to deal with environments which are not perfect,
but which users expect Freetype to work out of the box (and also, the
same way it performed in the past.)

Makes sense - out of interest, what is given up and why?

 

> If in the case, you make a change, and something isn't recompiled, doesn't
> this imply the dependency tree is incomplete or incorrect?

That is my assertion, yes. Which is why, to be on the safe side, it is
better to mark more files as changed, as the "install" target does.


Antoine

_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel