Hi Gustavo, On Wed, Mar 17, 2010 at 7:22 AM, Gustavo Noronha Silva <[email protected]> wrote: > While I agree with the rest of your email, I failed to understand the > actual problem this caused. Is it because the include path for > platform/graphics/cairo is coming before the one you were using, and > then picking up the wrong file on include?
Previously, FontPlatformData.h did not exist in the platform/graphics/cairo folder. Consequently, the FontPlatformData.h in the specific port directory (gtk, win, etc.) was always used when building FontCairo.cpp. However, by adding a local FontPlatformData.h to the cairo folder, this file now is preferentially used by the compiler, since FontCairo.cpp is currently built before the port-specific files and is in the immediate proximity of the compilation unit. gcc might not suffer from this problem, but MSVC always prefers a filename from the compilation unit's current directory to something in the search path. Consequently, changing order of search paths will not resolve this issue. So to resolve the build, there are a couple of options: 1. I can locally delete the platform/graphics/cairo/FontPlatformData.h, and everything reverts to a normal build for me. Obviously this is not viable for a long-term solution. 2. We can rename the various FontPlatformData.h (in win, gtk, etc.) to something like FontPlatformDataWin.h/FontPlatformDataGtk.h, etc. and use a chromium-like generic FontPlatformData.h that internally (using various #if/def tests) includes the specific xxxxWin.h, xxxxGtk.h, etc. needed for the current port. 3. We can refactor the current font logic to more properly separate the font representation from rendering engine, as proposed in my last e-mail. The quickest way to resolve things is probably #2, but I think #3 might be better for the project. -Brent _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
