improving commandline documentation/help
hello cabal devs, i am willing to put a bit of time into improving the help texts of cabal-install. some questions: 1) nobody else is working on this, right? is there risk that it interferes with other's work? (i'd basically touch Distribution.Simple.Command and the different fooCommand's in both Setup.hs's) 2) is there a specific reason that the help texts currently are so short, other than lack of time/focus on functionality? pending large changes or smth? 3) is there a policy to keep commits touching Cabal and cabal-install subdirectories separate (for git-subtree purposes, for example)? Lennart ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: improving commandline documentation/help
Hi, On 30 October 2014 16:22, lennart spitzner l...@informatik.uni-kiel.de wrote: hello cabal devs, i am willing to put a bit of time into improving the help texts of cabal-install. some questions: 1) nobody else is working on this, right? is there risk that it interferes with other's work? (i'd basically touch Distribution.Simple.Command and the different fooCommand's in both Setup.hs's) Not to my knowledge. 2) is there a specific reason that the help texts currently are so short, other than lack of time/focus on functionality? pending large changes or smth? Not really, feel free to go ahead and improve things. 3) is there a policy to keep commits touching Cabal and cabal-install subdirectories separate (for git-subtree purposes, for example)? No, and I think it's better to change both in lockstep so that there are no broken revisions in history. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: New fields/flags and semantics for GHCJS
On Wed, Oct 29, 2014 at 2:10 AM, Mikhail Glushenkov the.dead.shall.r...@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 ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: New fields/flags and semantics for GHCJS
# 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
