- cabal-devel - Haskell.org

Re: [Hackage] #98: cabal assumes -x option for linking
by Hackage 19 Oct '07

19 Oct '07

#98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder(a)dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): Maybe LDFLAGS should be appropriately set by configure and used in the sources instead of -x. Meanwhile the ghc-6.8.0.20071017 sources (without extra-libs) went through. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/98#comment:9> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

RE: -O in 6.8.1-candidate
by Duncan Coutts 19 Oct '07

19 Oct '07

On Fri, 2007-10-19 at 10:42 +0100, Simon Peyton-Jones wrote: > | In general the users should never have to modify the .cabal file. For > | the common settings that we expect the user to want to control Cabal > | provides configure flags. > | > > .... > > | The idea is that instead of having to find the options for each > | implementation you might want to use, that Cabal knows the right > options > | for each compiler to use a feature like optimisation or profiling or > | whatever. > > You have a clear mental model of how Cabal is intended to be used -- > although it also provides trapdoors (like ghc-options) for when the > intended path isn't adequate. But that mental model is much clearer > to you and the other Cabal developers than it is to Cabal users like > Serge and me. > > Would it be worth writing a new section in the Cabal manual that > describes the "intended use model" for Cabal, for the benefit of Cabal > users? That way you'd be able to explain this stuff once and for all. > > Documentation often focuses on the knobs ("turn the steering wheel to > make the car change direction"), and omit the larger mental model of > what is going on ("cars should be driven on a road"). Yes. Here's a new introduction for the user's guide. Comments and improvements welcome. Duncan <sect1 id="intro"> <title>Introduction</title> <para> Developers write Cabal packages. These can be for libraries or executables. This involves writing the code obviously and also creating a <literal>.cabal</literal> file. The .cabal file contains some information about the package. Some of this information is needed to actually build the package and some is just useful for identifying the package when it comes to distribution. </para> <programlisting> name: Foo version: 1.0 library build-depends: base exposed-modules: Foo </programlisting> <para> Users install Cabal packages so they can use them. It is not expected that users will have to modify any of the information in the <literal>.cabal</literal> file. Cabal does provide a number of ways for a user to customise how and where a package is installed. They can decide where a package will be installed, which Haskell implementation to use and whether to build optimised code or build with the ability to profile code. </para> <programlisting> tar -xzf Foo-1.0.tar.gz cd Foo-1.0 cabal-setup configure --with-compiler=ghc-6.4.2 --prefix=$HOME --user cabal-setup build cabal-setup install </programlisting> <para> One of the purposes of Cabal is to make it easier to build a package with different Haskell implementations. So it provides abstractions of features present in different Haskell implementations and wherever possible it is best to take advantage of these to increase portability. Where necessary however it is possible to use specific features of specific implementations. For example one of the pieces of information a package author can put in the package's <literal>.cabal</literal> file is what language extensions the code uses. This is far preferable to specifying flags for a specific compiler as it allows Cabal to pick the right flags for the Haskell implementation that the user picks. It also allows Cabal to figure out if the language extension is even supported by the Haskell implementation that the user picks. Where compiler-specific options are needed however, there is an "escape hatch" available. The developer can specify implementation-specific options and more generally there is a configuration mechanism to customise many aspects of how a package is built depending on the Haskell implementation, the Operating system, computer architecture and user-specified configuration flags. </para> <programlisting> name: Foo version: 1.0 library build-depends: base exposed-modules: Foo extensions: ForeignFunctionInterface ghc-options: -Wall nhc98-options: -K4m if os(windows) build-depends: Win32 </programlisting> </sect1>

1 0

Re: [Hackage] #98: cabal assumes -x option for linking
by Hackage 19 Oct '07

19 Oct '07

#98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder(a)dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by duncan): See also http://hackage.haskell.org/trac/ghc/ticket/1786#comment:2 where I describe one route to a fix. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/98#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Haskell] Re: Trying to install binary-0.4
by Simon Marlow 18 Oct '07

18 Oct '07

Several good points have been raised in this thread, and while I might not agree with everything, I think we can all agree on the goal: things shouldn't break so often. So rather than keep replying to individual points, I'd like to make some concrete proposals so we can make progress. 1. Document the version numbering policy. We should have done this earlier, but we didn't. The proposed policy, for the sake of completeness is: x.y where: x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical further sub-versions may be added after the x.y, their meaning is package-defined. Ordering on versions is lexicographic, given multiple versions that satisfy a dependency Cabal will pick the latest. 2. Precise dependencies. As suggested by various people in this thread: we change the convention so that dependencies must specify a single x.y API version, or a range of versions with an upper bound. Cabal or Hackage can refuse to accept packages that don't follow this convention (perhaps Hackage is a better place to enforce it, and Cabal should just warn, I'm not sure). Yes, earlier I argued that not specifying precise dependencies allows some packages to continue working even when dependencies change, and that having precise dependencies means that all packages are guaranteed to break when base is updated. However, I agree that specifying precise dependencies is ultimately the right thing, we'll get better errors when things break, There's lots more to discuss, but I think the above 2 proposals are a step in the right direction, agreed? Cheers, Simon

7 14

patch applied (cabal-branches/cabal-1.2): don't fail if xxx_hsc_make.c is gone
by Duncan Coutts 18 Oct '07

18 Oct '07

Thu Oct 18 09:42:45 PDT 2007 Ross Paterson <ross(a)soi.city.ac.uk> * don't fail if xxx_hsc_make.c is gone The non-GHC hsc2hs deletes it even if the compilation fails. M ./Distribution/Simple/Program.hs -1 +2

1 0

patch applied (cabal-branches/cabal-1.2): Correct the spelling of mingw32 in os alias list
by Duncan Coutts 18 Oct '07

18 Oct '07

Thu Oct 18 12:56:41 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Correct the spelling of mingw32 in os alias list Doh! M ./Distribution/Configuration.hs -1 +1

1 0

patch applied (cabal-branches/cabal-1.2): Update changelog for 1.2.1
by Duncan Coutts 18 Oct '07

18 Oct '07

Thu Oct 18 12:15:19 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Update changelog for 1.2.1 M ./changelog +13

1 0

Re: [Hackage] #98: cabal assumes -x option for linking
by Hackage 18 Oct '07

18 Oct '07

#98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder(a)dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): No, it did no work yet. It seems I have to edit `libraries/Cabal/Distribution/Simple/GHC/Makefile.in`, too! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/98#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #98: cabal assumes -x option for linking
by Hackage 18 Oct '07

18 Oct '07

#98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder(a)dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): Omitting this line works under Solaris. Maybe this explains why my binaries are about 20% bigger. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/98#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): don't fail if xxx_hsc_make.c is gone
by Ross Paterson 18 Oct '07

18 Oct '07

Thu Oct 18 09:42:45 PDT 2007 Ross Paterson <ross(a)soi.city.ac.uk> * don't fail if xxx_hsc_make.c is gone The non-GHC hsc2hs deletes it even if the compilation fails. M ./Distribution/Simple/Program.hs -1 +2

1 0