New fields/flags and semantics for GHCJS
Hi all, I've been maintaining a Cabal fork for GHCJS. The GHCJS-specific bits have been relatively stable for a while now, and are feature complete, apart from a few small features that I'll complete later this week. So I think it's time to discuss merging the branch. This discussion is for the user visible changes only, the implementation details can be discussed later when the code has been cleaned up for the merge (1-2 weeks). I hope that the proposed changes cover most JavaScript packaging/build requirements, but feature requests or questions about support for specific scenarios are welcome! First some background: GHCJS is a cross-compiler, installed as a package. It has its own version number (0.1.0 currently), independent of the GHC version it was built with. After GHCJS and its standard libraries have been installed, it does not require GHC anymore. Cabal's custom setup type is supported by compiling Setup.hs to JavaScript and running it with node.js. In the Cabal branch, GHCJS is treated as a very close relative of GHC. In various places there is support for GHCJS building native code. While this (--native-too mode) is currently disabled in a default installation, it can be enabled again for generating JavaScript and native code from the same Core, for example to allow closure serialization and continuing computations between client and server (not yet implemented!). All Cabal features are supported, including sandboxes. "cabal test" compiles the testsuite of a package and runs it with node.js. "cabal repl" is implemented on the Cabal side, but there is no repl for GHCJS yet, this is planned for the not too far future (with a terminal and browser based front end). The changes: # a new implementation flag: impl(ghcjs) A new implementation flag has been added for GHCJS, using the GHCJS version number. Since GHCJS is a close descendant of GHC, the impl(ghc) flag is also set when something is being built with GHCJS. For example if impl(ghc >= 7.2) -- GHC.Generics support (compiler could be GHCJS) if impl(ghcjs >= 0.1) -- package is being built with GHCJS # ghcjs-options, ghcjs-shared-options, ghcjs-prof-options These new fields behave similar to those for GHC (ghcjs-shared-options only has effect for native-too mode). If not set, the corresponding value from ghc-options, ghc-shared-options, ghc-prof-options is used. (An alternative is to let ghcjs-*-options field append the options to the corresponding ghc-*-options field, instead of replacing them) # 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. # new JavaScriptFFI extension The extension has been in GHC since 7.8, but it can't be used on non-JavaScript code generators. This change just adds it to the list of known extensions. luite
Hi,
On 28 October 2014 21:00, Luite Stegeman
Hi all,
I've been maintaining a Cabal fork for GHCJS. The GHCJS-specific bits have been relatively stable for a while now, and are feature complete, apart from a few small features that I'll complete later this week.
So I think it's time to discuss merging the branch. This discussion is for the user visible changes only, the implementation details can be discussed later when the code has been cleaned up for the merge (1-2 weeks).
The user-visible changes look reasonable in my opinion. Looking forward to merging your patches!
On Wed, Oct 29, 2014 at 2:10 AM, Mikhail Glushenkov < the.dead.shall.rise@gmail.com> wrote:
The user-visible changes look reasonable in my opinion. Looking forward to merging your patches!
When merging the latest master I found that ghcjs-options are actually mappended to ghc-options in the current implementation, instead of replacing them. The current version is here by the way: https://github.com/ghcjs/cabal/tree/ghcjs I still need to clean it up and check that all changes are still needed though, and implement the missing features. I'm also working on making GHCJS compatible with GHC 7.10 at the moment (and GHC 7.10 with GHCJS, a few patches going in that direction), so this will take a few days. luite
# 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
One more thing I had forgotten to mention, and still need to implement in GHCJS: If a library has web assets, for example CSS files or images for a GUI framework library, they should be listed under `data-files` of a package. The compiler then makes all data directories of dependencies available in a subdirectory of the directory containing the generated JavaScript and HTML files. Libraries then use their own "Paths_packagename" module to find the location. Location should probably be based on the package key, not the package version, so this requires #2194 to be resolved first.
participants (2)
-
Luite Stegeman -
Mikhail Glushenkov