New fields/flags and semantics for GHCJS

Luite Stegeman stegeman at gmail.com
Thu Oct 30 22:04:56 UTC 2014


>
>
> # 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20141030/a4e7b135/attachment.html>


More information about the cabal-devel mailing list