Extract use_system_foo logic out of gyp files, patch 2

build/linux/unbundle/libevent.gyp

Index: build/linux/unbundle/libevent.gyp
diff --git a/build/linux/unbundle/libevent.gyp b/build/linux/unbundle/libevent.gyp
new file mode 100644
index 0000000000000000000000000000000000000000..99d743533f6104c78d5106fa445f642f5eda2514
--- /dev/null
+++ b/build/linux/unbundle/libevent.gyp
@@ -0,0 +1,27 @@
+# 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': 'libevent',
+      'type': 'none',
+      'toolsets': ['host', 'target'],

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

I'm surprised to see this is necessary. Is this perhaps accidental/unnecessary
porting?

Having trouble seeing how the same link settings would work correctly for both
host and target. It's a different story when we're compiling, because we
generate different .o's and different libraries.

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

This is just what _was_ in use_system_libevent branch of the gyp file.

I'd strongly prefer to keep this CL just an extraction, not actual changes to
the code.

This option works as is. I can take a look later whether this is really
necessary.

Note that even when not cross-compiling, the build system will "instantiate"
build rules for host/target, where host==target anyway, but things will be built
twice. That's the most likely reason this code is here.

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

Since it sounds like you're unwilling to try to improve this CL, and that code
in build/linux/unbundle is "unsupported", I'm fine stamping this.

I'm still convinced it's wrong though. You should only need a toolset
declaration if a toolchain built separately for host/target depends on this, and
if it does, you will not get the correct build results here. I think the
original gyp for use_system_libevent was wrong - and it may even be that it's
unnecessary for the non-use_system_libevent.

I would love to think that the Chromium goal of "Leave things better than how
you found them" was practiced here, and this was investigated, but since this
isn't "really" Chromium code, I don't feel like it would be useful to block this
CL on cleaning it up. This will be something for those unbundling to maintain -
which admittedly is the whole goal of splitting this out.

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

Ryan, don't worry - I do care about quality. I just prefer to split trivial code
moves/extractions from changes which modify semantics.

I checked, and removal of it results in the following error on
build/gyp_chromium:

gyp: Dependency
'/home/phajdan/chromium/src/third_party/libevent/libevent.gyp:libevent#host' not
found while trying to load target
/home/phajdan/chromium/src/base/base.gyp:base#host

If there is something to be fixed there, I can do that - just in a separate CL,
this could get a bit larger as a cleanup.

+      'variables': {
+        'headers_root_path': '.',
+        'header_filenames': [
+          'event.h',
+        ],
+      },
+      'includes': [
+        '../../build/shim_headers.gypi',
+      ],
+      'link_settings': {
+        'libraries': [
+          '-levent',
+        ],
+      },
+    }
+  ],
+}