Re: building only the docs

On 30/12/2007, at 2:00 AM, Duncan Coutts wrote:
> cabal install --docs --everything-else
>
> What would the user interface be? Are there any other categories than
> docs? Is it additive, subtractive? Can the default be explained in  
> terms
> of the new proposed flags?

Interesting questions. I see in a related discussion with Bryan  
O'Sullivan you say:

>> By the way, is there a reason why a .cabal file can specify multiple
>> executables, but only one library?  LLVM wants to be built in a  
>> modular
>> fashion to minimise the number of dependencies, and it would be  
>> nice to
>> be able to put llvm-common, llvm-core, and llvm-engine all in a  
>> single
>> .cabal file, each with different ld-options.
>
> It's because we don't yet support building collections of related
> packages very well. There have been suggestions that when we do  
> support
> that better that there should only be one library or executable
> per .cabal file.

So what we really want is a way to say (at least) build/haddock/ 
install for each package/executable we're interested in as well. HaXml  
is one example, where I don't really care about the executables and  
just want the libraries + docs.

Re: [Hackage] #197: implement cabal upgrade (installs new versions of all packages)

#197: implement cabal upgrade (installs new versions of all packages)
---------------------------------+------------------------------------------
  Reporter:  ijones              |        Owner:         
      Type:  defect              |       Status:  closed 
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.2.3.0
  Severity:  normal              |   Resolution:  fixed  
  Keywords:                      |   Difficulty:  normal 
Ghcversion:  6.8.2               |     Platform:  Linux  
---------------------------------+------------------------------------------
Comment (by duncan):

 I'm glad this is in, I just want to think about the user interface for a
 moment; for these variations on installing/upgrading stuff, what mix of
 top level commands or modifying flags they should use.

 So at the moment the behaviour is:

 {{{
 cabal install foo
 }}}
 means install the package foo only if it is not already installed. If a
 newer version is available it is ignored. Though if someone specifies
 {{{cabal install foo-1.1}}} then that really will be installed, even if
 foo-1.0 is installed already. This is probably not what most people want
 (see #168 & #198).

 {{{
 cabal upgrade
 }}}

Re: [Hackage] #198: outline for revamp of "cabal install" and upgrade behavior

#198: outline for revamp of "cabal install" and upgrade behavior
---------------------------------+------------------------------------------
  Reporter:  guest               |        Owner:         
      Type:  defect              |       Status:  new    
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.2.3.0
  Severity:  normal              |   Resolution:         
  Keywords:                      |   Difficulty:  normal 
Ghcversion:  6.8.2               |     Platform:  Linux  
---------------------------------+------------------------------------------
Changes (by ijones):

  * summary:  cabal install foo should upgrade foo if there's a newer
              version => outline for revamp of "cabal
              install" and upgrade behavior

Old description:

> As in #168
>
> if I have foo-1.0 installed, and foo-2.0 is available, "cabal install
> foo" should upgrade foo to version 2.0
>
>  1. If the user specifies a package without a version, and a newer
> version is available on Hackage, that newer version should be installed.
>  2. If the system is installing dependencies on "foo", if the dependency
> can be satisfied locally, do not install the "hackage" version, even if
> it's newer.
>  1. If a user specifies a specific version
>    1. if that version is available locally, use that

Re: [Hackage] #197: implement cabal upgrade (installs new versions of all packages)

#197: implement cabal upgrade (installs new versions of all packages)
---------------------------------+------------------------------------------
  Reporter:  ijones              |        Owner:         
      Type:  defect              |       Status:  closed 
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.2.3.0
  Severity:  normal              |   Resolution:  fixed  
  Keywords:                      |   Difficulty:  normal 
Ghcversion:  6.8.2               |     Platform:  Linux  
---------------------------------+------------------------------------------
Old description:

> much like apt-get, we should have a way to upgrade all of the packages to
> the latest version.
>
> "cabal upgrade" is probably a good name.

New description:

 See [ticket:198 continued discussion].

 much like apt-get, we should have a way to upgrade all of the packages to
 the latest version.

 "cabal upgrade" is probably a good name.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/197#comment:4>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

Re: [Hackage] #168: Behaviour of cabal-install with respect to upgradeable packages is unexpected

#168: Behaviour of cabal-install with respect to upgradeable packages is
unexpected
---------------------------------+------------------------------------------
  Reporter:  guest               |        Owner:                
      Type:  enhancement         |       Status:  closed        
  Priority:  normal              |    Milestone:                
 Component:  cabal-install tool  |      Version:  1.2.0         
  Severity:  normal              |   Resolution:  duplicate     
  Keywords:                      |   Difficulty:  hard (< 1 day)
Ghcversion:  6.4.2               |     Platform:  Linux         
---------------------------------+------------------------------------------
Changes (by ijones):

  * status:  new => closed
  * resolution:  => duplicate

Old description:

> When an old version of a package is already installed, running cabal-
> install to install it should install the latest available version of the
> package, rather than complaining that the package is already installed.
> (Or at least interactively provide the option to do so.)
>
> Having it simply abort without doing anything is strange because in the
> most common case a user tries to install a package because they need it
> and do not already have it. If the package is already installed, that
> probably means that they do not have a recent enough version of the
> package.
>
> It would also make cabal-install more apt-like, which is probably a good

Re: [Hackage] #198: outline for revamp of "cabal install" and upgrade behavior

#198: outline for revamp of "cabal install" and upgrade behavior
---------------------------------+------------------------------------------
  Reporter:  guest               |        Owner:         
      Type:  defect              |       Status:  new    
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.2.3.0
  Severity:  normal              |   Resolution:         
  Keywords:                      |   Difficulty:  normal 
Ghcversion:  6.8.2               |     Platform:  Linux  
---------------------------------+------------------------------------------
Old description:

> I'm consolidating #168 and #197 here.
>
> = Use cases =
>  * "cabal install world --deep" (upgrades all packages, whether required
> or not)
>    * do we delete obsolete packages too?
>  * "cabal install world" (upgrades only "interesting" packages and any
> required upgrades)
>  * "cabal install foo" (upgrades foo and any required upgrades from foo)
>  * "cabal install foo --deep" (upgrades foo and all its dependencies
> whether required or not)
>
> = Definitions =
>  * '''Interesting packages''' are packages that a user specifically
> requests, rather than a package that's installed because of a dependency.
>  * '''Obsolete packages''' are packages which were installed as a
> dependency on an interesting package, but are no longer depended on by
> any interesting package.

Re: [Hackage] #198: outline for revamp of "cabal install" and upgrade behavior

#198: outline for revamp of "cabal install" and upgrade behavior
---------------------------------+------------------------------------------
  Reporter:  guest               |        Owner:         
      Type:  defect              |       Status:  new    
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.2.3.0
  Severity:  normal              |   Resolution:         
  Keywords:                      |   Difficulty:  normal 
Ghcversion:  6.8.2               |     Platform:  Linux  
---------------------------------+------------------------------------------
Old description:

> I'm consolidating #168 and #197 here.
>
> = Use cases =
>  * "cabal install world --deep" (upgrades all packages, whether required
> or not)
>    * do we delete obsolete packages too?
>  * "cabal install world" (upgrades only "interesting" packages and any
> required upgrades)
>  * "cabal install foo" (upgrades foo and any required upgrades from foo)
>  * "cabal install foo --deep" (upgrades foo and all its dependencies
> whether required or not)
>
> = Definitions =
>  * '''Interesting packages''' are packages that a user specifically
> requests, rather than a package that's installed because of a dependency.
>    * If someone specifies a version number, is that version itself
> "interesting"?
>  * '''Obsolete packages''' are packages which were installed as a

Re: [Hackage] #189: Handle framework paths (-F) in Cabal

#189: Handle framework paths (-F) in Cabal
----------------------------+-----------------------------------------------
  Reporter:  guest          |        Owner:         
      Type:  enhancement    |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:  1.2.2.0
  Severity:  normal         |   Resolution:         
  Keywords:                 |   Difficulty:  normal 
Ghcversion:  6.8.2          |     Platform:  Mac OS 
----------------------------+-----------------------------------------------
Changes (by guest):

  * ghcversion:  6.8.1 => 6.8.2

Comment:

 cabal should not need to pass `$HOME/Library/Frameworks` to ghc. ghc
 itself should pass `-F$HOME/Library/Frameworks` to gcc and the linker on
 Macs. See my (most recent) file `DriverPipeline.hs` in
 http://hackage.haskell.org/trac/ghc/ticket/1395


 Christian (.Maeder <at> dfki.de)

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/189#comment:2>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

#189: Handle framework paths (-F) in Cabal
----------------------------+-----------------------------------------------

Re: building only the docs

On Sat, Dec 29, 2007 at 07:00:49PM +0000, Duncan Coutts wrote:
> 
> On Mon, 2007-12-24 at 12:10 +0000, Ian Lynagh wrote:
> > 
> > Related to this, there'e no way to install only the docs or only the
> > binaries when both are built, as far as I know. This isn't a huge
> > problem, but it ought to be easy to fix and it would be nice to have.

Oh, another thing that would make my life a lot easier is a flag for
whether or not to install the license file.

> > It would have made things slightly simpler for me when building separate
> > -doc and -dev Debian packages for Cabal libraries, and it also would
> > mean we could do the right thing in GHC's "make install-docs".
> 
> cabal install --docs --everything-else
> 
> What would the user interface be? Are there any other categories than
> docs?

OTTOMH, there's a tree of things like:

all
    docs
        haddock-interfaces
        html
    license
    binaries
        library
        executables

Re: GHC's CPP and Cabal's unlit

On Sun, Dec 30, 2007 at 01:40:44AM +0000, Duncan Coutts wrote:
> 
> One bit I'm less sure about is the handling of paragraphs in comments.
> Currently the code transforms:
> 
> blah blah
> 
> blah blah
> 
> into
> 
> -- blah blah
> 
> -- blah blah
> 
> but it transforms
> 
> blah blah
>  
> blah blah
> 
> into
> 
> -- blah blah
> --  
> -- blah blah
> 
> spot the difference? Yeah, just white space. The completely blank line
> separates the paragraphs into two comments which haddock will treat
> differently from a single comment.