plugins: don't copy into product_dir/plugins

plugins: eliminate use of product_dir

The 'product_dir' variable in gyp is only implemented by the
scons generator and only used by plugins, and the
plugin tests don't yet run on Linux (where we use scons).

The npapi_layout_test_plugin is copied into the proper place
for layout tests with a 'copy' rule.

BUG=15695

[Evan Martin, 2009-06-30 01:09:46]

Not sure about this, but it's how I read the code.

Amanda: will this affect Mac at all?

[Evan Martin, 2009-06-30 01:11:03]

PS:

% grep -l product_dir tools/gyp/pylib/gyp/generator/*
tools/gyp/pylib/gyp/generator/scons.py
tools/gyp/pylib/gyp/generator/scons.pyc

[Amanda Walker, 2009-06-30 01:33:06]

This won't affect the NPAPI test plugin (used by the plugin unit tests), but it
may affect the layout test plugin, which layout tests use to confirm that
JS<->NPAPI communication works as expected.  If we don't put that plugin
somewhere that TestShell can find it at build time, we need to make sure that
the run-webkit-tests.py script copies it before it fires off a test run.

[Evan Martin, 2009-06-30 01:40:04]

On 2009/06/30 01:33:06, Amanda Walker wrote:
> This won't affect the NPAPI test plugin (used by the plugin unit tests), but
it
> may affect the layout test plugin, which layout tests use to confirm that
> JS<->NPAPI communication works as expected.  If we don't put that plugin
> somewhere that TestShell can find it at build time, we need to make sure that
> the run-webkit-tests.py script copies it before it fires off a test run.

Hrm, even layout_plugin_uitest has this comment:

  // We need to copy our test-plugin into the plugins directory so that
  // the browser can load it.
  std::wstring plugins_directory = browser_directory_.ToWStringHack();
  plugins_directory += L"\\plugins";
  std::wstring plugin_src = browser_directory_.ToWStringHack();
  plugin_src += L"\\npapi_layout_test_plugin.dll";
  std::wstring plugin_dest = plugins_directory;
  plugin_dest += L"\\npapi_layout_test_plugin.dll";

  CreateDirectory(plugins_directory.c_str(), NULL);
  CopyFile(plugin_src.c_str(), plugin_dest.c_str(), true /* overwrite */);


Maybe it's just double-checking it's in the correct dir?

[Amanda Walker, 2009-06-30 01:42:15]

All of the unit tests will work--it's TestShell running the WebKit layout tests
that does not have a copy step (currently).

[Evan Martin, 2009-06-30 20:13:47]

Ok, new try.

I left in the copy step, to handle awalker's comment.  From the file:
          'copies': [
            {
              'destination': '<(PRODUCT_DIR)/plugins',
              'files': ['<(PRODUCT_DIR)/npapi_layout_test_plugin.dll'],
            },

[Evan Martin, 2009-06-30 20:23:46]

TBRing this due to broken build, will revert if something goes wrong

[jam, 2009-07-18 03:18:02]

So I'm seeing a problem with this.  If I build ui_tests.exe and then try to
run tests like NPAPITester.SelfDeletePluginInvoke, they fail because the
plugin isn't copied there.
Perhaps when these tests are run on the bot, they pass because a previous
step copied the dll.

On Tue, Jun 30, 2009 at 1:23 PM, <evan@chromium.org> wrote:

> TBRing this due to broken build, will revert if something goes wrong
>
>
> http://codereview.chromium.org/150085
>

[sgk, 2009-07-20 17:07:47]

What's the final resolution on this?

The intent of product_dir (modulo someone picking a better name) was to provide
a way for an individual target to specify where it wants its products built,
without having to cut-and-paste manual 'copies' steps all over the
configuration.

Was this actually causing problems?  If so, then this change lgtm, and it has
the advantage of cutting down on the clutter of Yet Another feature.

But it seems like the generic ability to say "this target's output should go
*here*" is common enough that a more compact idiom than a cut-and-paste manual
copy would be useful.  Comments?