Avoid double compiles of libjpeg

When libyuv was changed to compile with clang-cl this also cause libjpeg
to be compiled with clang-cl, which means that it was being compiled
twice. This is generally a bad practice, it was causing duplicate symbol
warnings in some builds, and it slows builds slightly. This change
reduces the number of build steps with the default gn settings on
Win64 builds by 71 (currently from 47,200 to 47,129).

See this change that change libyuv's compilation:
https://chromium-review.googlesource.com/c/446667/

BUG=706627

Change-Id: I13e2d4ff8511350901af10f7443f3f4b89cc2499
Reviewed-on: https://chromium-review.googlesource.com/456651Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Henrik Kjellander <kjellander@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>

BUILD.gn

@@ -45,6 +45,7 @@ group("libyuv") {
   public_configs = [ ":libyuv_config" ]
 
   if (is_win && target_cpu == "x64") {
+    # Compile with clang in order to get inline assembly
     public_deps = [
       ":libyuv_internal(//build/toolchain/win:clang_x64)",
     ]
@@ -53,9 +54,20 @@ group("libyuv") {
       ":libyuv_internal",
     ]
   }
+
+  if (!is_ios) {
+    # Make sure that clients of libyuv link with libjpeg. This can't go in
+    # libyuv_internal because in Windows x64 builds that will generate a clang
+    # build of libjpeg, and we don't want two copies.
+    deps = [
+      "//third_party:jpeg",
+    ]
+  }
 }
 
 static_library("libyuv_internal") {
+  visibility = [ ":*" ]
+
   sources = [
     # Headers
     "include/libyuv.h",
@@ -122,7 +134,10 @@ static_library("libyuv_internal") {
 
   if (!is_ios) {
     defines += [ "HAVE_JPEG" ]
-    deps += [ "//third_party:jpeg" ]
+
+    # Needed to pull in libjpeg headers. Can't add //third_party:jpeg to deps
+    # because in Windows x64 build it will get compiled with clang.
+    deps += [ "//third_party:jpeg_includes" ]
   }
 
   if (libyuv_use_neon) {