- cabal-devel - Haskell.org

Re: [Hackage] #179: support GHC's main-is extension
by Hackage 07 Jun '11

07 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by benmachine): There's a difference between Cabal ''code'' containing platform-specific stuff and the Cabal ''file syntax'' catering to specific platforms. The latter is much harder to change, and whatever syntax people come up with usually has to be supported for years afterwards. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:18> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #179: support GHC's main-is extension
by Hackage 07 Jun '11

07 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by Evi1M4chine): Replying to [comment:15 cjs]: I just checked the Cabal source, and there’s already tons of compiler- specific stuff in there. Basically there are separate files for each compiler, and even a whole directory named GHC. So they are way beyond “We can’t write something specifically for one compiler.”. Because basically, the whole code relies on code specific to certain compilers. Also it’s pretty easy to extend (for a Cabal developer). Just add a field to the “Executable” data type in Distribution.PackageDescription, and only make the GHC implementation not ignore it, when building the GHC command line. Done. About 5-10 minutes for a Cabal developer. (Unless I’m missing something, like Unit tests, etc, of course.) Hey, if any Cabal developer reads this: Is there anything we can make, to give you a motivation to do it? Money? A good beer? Something you need? Or a way to put it in that respects the project philosophies? If I’m able to provide it, I will. Just ask, man. :) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:17> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: mouseover types via hscolour, haddock, cabal
by David Waern 06 Jun '11

06 Jun '11

2011/6/6 Ranjit Jhala <jhala(a)cs.ucsd.edu>: > > Yes, I did know that. The difference is that here you have > the types for _every_ identifier that occurs in a program, > not just the top-level bindings that the hoogle database > contains. This allows HsColour to display the type of any > arbitrary identifier if one puts the mouse over the > occurrence of the identifier in the HTML text. > > Right now, one could "simulate" this by entering the name > of the identifier into Hoogle and getting the type out, but > this (tedious) process only works for the subset of identifiers > indexed by hoogle. Ah, good point. >> About the dependency, I don't think we can depend on syb as it's not a >> GHC boot library. (Haddock is used in the GHC build process and can >> only depend on boot libraries). syb was moved out of the boot >> libraries a while ago, unfortunately. > > Ah! I had imagined since the various types in GHC were all > instances of Data and Typeable, that GHC would depend on syb. > Do you know if there is some other generic library that GHC > depends on? If not, it may be easiest to have Haddock call "Annot" > as a separate binary (as it does HsColour...) Data and Typeable are defined separately from syb, syb just uses them. GHC currently doesn't use any generics library. I suppose we could start a discussion about which generics library GHC and Haddock should use. I don't think it necessarily needs to be syb, but one thing is sure - it would be very convenient to have one. About the output: I noticed that in the HTML some of the names point to the wrong type, e.g Interface points to ifaceRnDocMap. Also some of the types look quite "raw" and could be simpler, e.g. the type of Monad. And many of the names don't have tool-tips at all. Are these part of the improvements you plan to make? Just making sure we don't miss something. I'm happy to include the Annot backend if we solve the syb issue. However you should know that the long term plan is to make the backends stand-alone programs. The idea is that Haddock should produce one single file containing everything useful that it knows about the package. David

1 0

Re: mouseover types via hscolour, haddock, cabal
by David Waern 06 Jun '11

06 Jun '11

Hi Ranjit, 2011/6/1 Ranjit Jhala <jhala(a)cs.ucsd.edu>: > Hi all, > > I have just modified HsColour, Haddock and Cabal in order to produce HTML > sources where the types of the identifiers are displayed when the mouse > hovers over the identifier. You can see the results for HsColour, Haddock > and Cabal at: > > http://goto.ucsd.edu/~rjhala/Annot/ Cool stuff! > * Haddock: takes a --annot=FILE option, and generates a text database as > described above. This could be useful even in other settings, e.g. to > display identifier types within emacs/vim (the current approaches, at > least for vim only show types for top-level bindings...) > New dependency: syb (to walk over the GHC AST and extract type bindings) Hmm, do you know that Haddock can already generate a Hoogle database? If so, is this database significantly different? About the dependency, I don't think we can depend on syb as it's not a GHC boot library. (Haddock is used in the GHC build process and can only depend on boot libraries). syb was moved out of the boot libraries a while ago, unfortunately. Thanks for the patch, I will take a look at it. David

1 0

[Patches] Various things related to building .app bundles
by Dan Knapp 02 Jun '11

02 Jun '11

9 patches for repository http://darcs.haskell.org/cabal: Fri May 27 19:25:44 EDT 2011 Dan Knapp <dankna(a)gmail.com> * Pursuant to Cabal ticket #850. Fix for "C" headers specified with includes: which are actually ObjectiveC headers (or some other dialect). Works by asking the C compiler which source files include which headers, then inferring the dialects of those source files from their filenames, combining the resulting dialects for each header with a monoid, and mapping the final dialect back onto a filename extension for the dummy file to be used in the foreign-library tests. Sat May 28 08:15:56 EDT 2011 Dan Knapp <dankna(a)gmail.com> * One-line fix to the prior patch for ticket #850; I had omitted a case in my declaration for the Monoid CDialect instance. Sat May 28 08:30:22 EDT 2011 Dan Knapp <dankna(a)gmail.com> * Pursuant to ticket #504, expand the check for a known extension on the file provided to main-is: to also allow known C-language extensions. This uses my Distribution.Simple.CCompiler from the ticket #850 patch so that the information on known extensions isn't duplicated. The ticket #504 discussion suggests that ghc needs -no-hs-main in this situation, but that appears to no longer be the case; also see discussion on GHC ticket #2459. There might still be an issue if the entry point is WinMain() instead of main(), but I'm not really set up to test that. Sat May 28 12:19:21 EDT 2011 Dan Knapp <dankna(a)gmail.com> * Change to my earlier patch for ticket #504, executables with a C main function. I swear this worked for me in my test case, but I found that it doesn't work now, and I can't see how it ever did. The issue is that, when looking for the source file, the new C extensions weren't known so it didn't come up. I added knowledge about them by making Distribution.Simple.PreProcess depend on Distribution.Simple.CCompiler. Sat May 28 20:56:14 EDT 2011 Dan Knapp <dankna(a)gmail.com> * Enhancement as requested by my ticket #851: a c-source-dirs field in BuildInfo. Implemented for configure, build, and sdist, which should be everything. Sat May 28 22:06:06 EDT 2011 Dan Knapp <dankna(a)gmail.com> * My fix for #851 actually broke my earlier fix for #850; this patch corrects things so they play nice together. Sun May 29 04:55:44 EDT 2011 Dan Knapp <dankna(a)gmail.com> * Fix the regression described in #852 and caused by my patch for #850. Sun May 29 21:23:50 EDT 2011 Dan Knapp <dankna(a)gmail.com> * Changes to handle building C source after Haskell source when making mixed-language executables, pursuant to ticket #852, so that C source can include *_stub.h files which are generated by the Haskell compilation. (This should already work in the library case.) Since ghc --make can't by itself infer the modules that need to be built when it's passed a .c file, we need to tell it. Tue May 31 04:43:24 EDT 2011 Dan Knapp <dankna(a)gmail.com> * Fix for ticket #853, passing the appropriate ObjC-GC flag to ghc and gcc when it's needed, based on a new BuildInfo field objc-gc: with the values Disabled (passes nothing), Optional, and Mandatory. -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

1 0

Re: mouseover types via hscolour, haddock, cabal
by Malcolm Wallace 01 Jun '11

01 Jun '11

> * HsColour: takes a new -acss=FILE option, where the FILE is a text file > corresponding to a database of identifiers/source-locations and types, > and renders an HTML document with the appropriate mouseover text (using > an extended .css file.) > New dependency: containers (Data.Map to hold the location -> annotation maps) I am OK with adding the new dependency. Only one very minor request: can we have the same option name (--annot instead of -acss) as the other tools please? It is better for consistency, reduces the memory burden on those who use the tools manually, and since the file is not actually a CSS file, may reduce potential confusion with (for instance) the -icss option. Thanks for this useful improvement to our community documentation standards! Regards, Malcolm

1 0

Re: [Hackage] #504: executables with a C main function
by Hackage 31 May '11

31 May '11

#504: executables with a C main function ------------------------------+--------------------------------------------- Reporter: duncan | Owner: dankna Type: enhancement | Status: assigned Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Changes (by dankna): * owner: => dankna * status: new => assigned -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/504#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #583: create application bundles on demand
by Hackage 31 May '11

31 May '11

#583: create application bundles on demand ----------------------------+----------------------------------------------- Reporter: kowey | Owner: dankna Type: enhancement | Status: assigned Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ----------------------------+----------------------------------------------- Changes (by dankna): * owner: => dankna * status: new => assigned -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/583#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #850: Configure fails when an Objective-C .h file is specified
by Hackage 31 May '11

31 May '11

#850: Configure fails when an Objective-C .h file is specified ----------------------------+----------------------------------------------- Reporter: dankna | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: configure mac objective-c Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When configuring a library or executable which has specified a C header with includes: in its .cabal file, and that header is actually Objective-C or includes other headers which are, configure fails. This is because of the test that Cabal does to determine whether all prerequisite C libraries are present, in which it compiles with gcc directly rather than going through the Haskell compiler as it does in the build phase. I'm working on a patch to this and should have it in about an hour. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/850> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #851: Add c-source-dirs: field analogous to hs-source-dirs: and include-dirs:
by Hackage 31 May '11

31 May '11

#851: Add c-source-dirs: field analogous to hs-source-dirs: and include-dirs: ----------------------------+----------------------------------------------- Reporter: dankna | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I came across this need in the course of working with a hybrid Haskell- ObjC project; it just seems weird to set include-dirs but not set this, since it happens in my project to be the same directory. Should be an easy feature; I'm going to implement it and keep track of my progress here. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/851> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1