Windows编译Skia时找不到libjpeg.h与libpng.h的问题求助

我之前在Windows上编译Skia时也碰到过一模一样的问题——明明官方文档说依赖会自动处理，结果还是报头文件找不到，手动加include路径也没用。给你几个实际有效的排查和解决方向：

• 先确认第三方依赖是否同步完整
  Skia的第三方依赖（包括libpng、libjpeg-turbo）是通过depot_tools管理的，很多人会跳过同步依赖的步骤，直接拉完Skia源码就开始构建。你可以在Skia根目录下执行这个命令，确保所有依赖都拉到了正确位置：

  python tools/git-sync-deps
  

  这个命令会自动把缺失的第三方库下载到third_party/externals目录下，同步完成后再重新构建试试。

• 不要手动指定extra_cflags，重新生成构建配置
  你手动添加的include路径可能因为Windows路径格式问题或者相对路径错误没生效，而且is_official_build=true的官方构建参数本来就应该自动包含这些依赖的路径。建议先清理之前的构建目录，重新生成配置：

  1. 删除Skia根目录下的out/Static文件夹
  2. 重新执行GN生成命令：

     bin/gn gen out/Static --args='is_official_build=true'
     

  3. 再运行ninja编译：

     ninja -C out/Static
     

• 检查depot_tools的环境配置
  确保depot_tools已经正确添加到系统PATH中，而且你是在Skia根目录下打开的命令行（PowerShell或CMD）执行构建命令。有时候环境变量没生效，会导致GN无法正确找到依赖库的位置。

• 尝试Debug构建排查问题
  如果官方构建还是有问题，可以先试试Debug构建，看是否能正常找到头文件：

  bin/gn gen out/Debug --args='is_debug=true'
  ninja -C out/Debug
  

  如果Debug构建正常，那可能是官方构建的某些参数意外禁用了png/jpeg支持。你可以打开out/Static/args.gn文件，检查是否有类似skia_use_libpng=false或skia_use_libjpeg_turbo=false的配置，如果有的话改成true，再重新编译。

内容的提问来源于stack exchange，提问作者david