Extract use_system_foo logic out of gyp files, patch 2

build/linux/unbundle/libwebp.gyp

Index: build/linux/unbundle/libwebp.gyp
diff --git a/build/linux/unbundle/libwebp.gyp b/build/linux/unbundle/libwebp.gyp
new file mode 100644
index 0000000000000000000000000000000000000000..6dbce2e3ab876cf003a5e8a01b7d595731b2517a
--- /dev/null
+++ b/build/linux/unbundle/libwebp.gyp
@@ -0,0 +1,28 @@
+# Copyright 2013 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+{
+  'targets': [
+    {
+      'target_name': 'libwebp',
+      'type': 'none',
+      'direct_dependent_settings': {
+        'defines': [
+          'ENABLE_WEBP',
+        ],
+      },
+      'link_settings': {
+        'libraries': [
+          # Check for presence of webpdemux library, use it if present.

[Ryan Sleevi, 2013/04/25 22:19:19]

I don't suppose you can just treat this as a variable?

I thought you were among the (many) who hate automagic dependencies, which this
definitely seems to be.

[Paweł Hajdan Jr., 2013/04/25 22:41:50]

I could make it require libwebp-0.3...
I think it's not. We always depend on libwebp (as compared to detecting its
absence and silently disabling libwebp support). When system version of libwebp
changes, SONAME will make it do the right thing. I have tested various
scenarios, and I think this works.

Eventually we'll be able to drop this compatibility code and always require
-lwebpdemux.

[Ryan Sleevi, 2013/04/25 23:12:40]

How is this not exactly that - attempting to detect -lwebpdemux support, and
silently disabling it if not present?

I don't feel strongly about this, since this is in the 'unmaintained' area, but
it seems worth calling out.

[Paweł Hajdan Jr., 2013/04/26 00:55:18]

I'll take a closer look at how libwebp handles SONAME bump there. libwebp.so's
SONAME is the same between libwebp-0.2 and libwebp-0.3, which is a bit
suspicious - but this will require some more looking and testing before I say
something more.
Thank you for being persistent in bringing this to my attention - it could be an
issue I have overlooked.

[Paweł Hajdan Jr., 2013/04/26 18:21:40]

I have further investigated this. Chrome binary built against libwebp-0.2 works
when linked against libwebp-0.3 . Backward compatibility of libwebp library is
preserved. Binary linked against libwebp-0.3's libwebpdemux will not run against
libwebp-0.2, but I'm not aware of expectations of such forward compatibility in
the Linux world.

As far as I can tell things are OK here.

+          '<!(python <(DEPTH)/tools/compile_test/compile_test.py '
+          '--code "int main() { return 0; }" '
+          '--run-linker '
+          '--on-success "-lwebp -lwebpdemux" '
+          '--on-failure "-lwebp" '
+          '-- -lwebpdemux)',
+        ],
+      },
+    }
+  ],
+}