New fields/flags and semantics for GHCJS
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
> 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
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
determine what to do based on the extension. Compilers should ignore
*.js.extension arguments for unrecognized extensions to allow reasonable
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cabal-devel