> > > # new js-sources field > > A js-sources field is treated like the c-sources field. JS sources of all > dependencies of a an executable are collected into a big JavaScript file. > GHCJS also outputs some data about the collected files for custom > deployment scripts. > > JS sources are not compiled, but are run through the C preprocessor. Since > running the same file through the preprocessor twice is problematic, and > it's very useful to be able to set some preprocessor options at link time > (for example -DGHCJS_BROWSER, which removes node.js-specific code), the > strategy is as follows: > > - When a library is being installed, the js-sources are copied to the > library installation directory, but not run through the preprocessor. the > cpp options are saved in the installation dir > - When building an executable, the JS-sources are collected. Each JS > source is processed with its own saved cpp-options with the cpp-options for > building the executable appended. > > A downside of this approach is that it'd affect how `#include` works. We could add the location where the `data-files` are installed to the include path, so the to be included scripts can just be listed under `data-files`. It doesn't feel quite ideal to use `data-files` for this, so suggestions are welcome!
Another thing I forgot to mention is that non-js files can also be listed under this field. For example if we have a Google Closure Compiler externs file for a script, we'd use: js-sources: script.js script.js.externs Would cause both files to be installed with the library, and passed to the compiler when linking, when building JavaScript. It's up to the compiler to determine what to do based on the extension. Compilers should ignore *.js.extension arguments for unrecognized extensions to allow reasonable backwards compatibility. luite
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
