Use 'frog' in apidoc. Also fix broken dependencies.

dart/utils/apidoc/apidoc.gyp

Index: dart/utils/apidoc/apidoc.gyp
diff --git a/dart/utils/apidoc/apidoc.gyp b/dart/utils/apidoc/apidoc.gyp
index 5ce55f83ab543ca565bd7755f5adf4a5cefb89c9..b438042cb0f55d661bf3575c262365157f3d094f 100644
--- a/dart/utils/apidoc/apidoc.gyp
+++ b/dart/utils/apidoc/apidoc.gyp
@@ -15,17 +15,20 @@
         {
           'action_name': 'run_apidoc',
           'inputs': [
-            '<(PRODUCT_DIR)/dart',
+            '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)dart<(EXECUTABLE_SUFFIX)',
+            '<(PRODUCT_DIR)/frog/bin/frog',
             '<!@(["python", "scripts/list_files.py"])',
           ],
           'outputs': [
-            '<(PRODUCT_DIR)/api_docs',
+            '<(PRODUCT_DIR)/api_docs/index.html',

[Bob Nystrom, 2012/04/23 16:03:20]

Does it matter that all of the other generated HTML isn't listed as an output
here?

[ahe, 2012/04/24 10:31:02]

That depends. I would like to identify the last file that apidoc writes out.
Would it be OK to call docIndex() as the last thing in Dartdoc.document?

However, the file index.html is not created atomically, so if you abort the
build you may get a partial index.html with a fresh timestamp.

Perhaps a simpler (and better) alternative is to write out a timestamp file at
the end of main() in apidoc.dart.

WDYT?

[Bob Nystrom, 2012/04/24 16:38:08]

We could do that, but that's likely to be brittle as apidoc and dartdoc change
over time. And, actually, I think right now the last thing that will be
generated is the client-side JS files since those are done async and don't even
start until main() has returned and all of the other sync operations are done.

I'm a gyp noob. What is this used for? Is it just to tell when this build step
is dirty and needs to be re-run?
Hmm, we could do that, but putting code in apidoc specifically to make gyp happy
feels weird to me. How about we add another little python action here that just
writes a timestamp file after the main action is done? That way all of the gyp
magic is confined to gyp.

[ahe, 2012/04/25 08:40:38]

This is not to make GYP happy. Any tool that participates in an incremental
build system needs to have certain behavior. Otherwise, you always need to wrap
the tool in another tool that runs it, and then atomically moves the result to
the right location. I know you can do that for a directory on Unix, but I'm not
sure about Windows.

Regardless, I think a tool provider needs to think about how his tool can be
used in a build system. Unlike javac and javadoc.

[ahe, 2012/04/25 08:42:45]

The last thing that happens is that the exit code of the compilation is checked.
However, the compilation is happening in parallel (in its own process).

+            '<(PRODUCT_DIR)/api_docs/client-live-nav.js',
           ],
           'action': [
-            '<(PRODUCT_DIR)/dart',
+            '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)dart<(EXECUTABLE_SUFFIX)',
             'apidoc.dart',
             '--out=<(PRODUCT_DIR)/api_docs',
-            '--mode=live-nav'
+            '--mode=live-nav',
+            '--compiler=<(PRODUCT_DIR)/frog/bin/frog',
           ],
         },
       ],