June 2011 - cabal-devel

Re: [Hackage] #543: ghc global package db should live in /var not /usr
by Hackage 24 Jun '11

24 Jun '11

#543: ghc global package db should live in /var not /usr ----------------------------+----------------------------------------------- Reporter: nr | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- Comment(by Syzygies): The real problem is accepting the dubious, ancient custom of scattering an installation across multiple bin, lib, share, doc directories rather than localizing everything in say /usr/local/ghc-7.0.4a. Giving the installing user write permission for this directory avoids the need for root permissions, and can insure that the install actually takes place exclusively within this directory. I'm baffled how others do side-by-side installs of different versions of GHC without following such a scheme. I'm opposed to this /var proposal. The convention of spraying files across hell and high water is what's broken, and we should do nothing to make matters worse. Adding /var to the spray list would be making matters worse. A number of modern projects similar to GHC default to localized installs in the style of /usr/local/ghc-7.0.4a; we should do the same. GHC is important enough to warrant a separate PATH entry, or aliases in /usr/local/bin. "This is one reason we do per-user installs by default." Cabal should check for a global config file parallel to `which ghc` according to the current path, defaulting to global installs and ignoring ~/.cabal/config if possible. The existence of ~/.cabal/config is like a global variable, and interferes with multiple side-by-side installations of GHC. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/543#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): "Add files needed by the GHC build system"
by Ian Lynagh 23 Jun '11

23 Jun '11

Thu Jun 23 17:36:54 PDT 2011 Ian Lynagh <igloo(a)earth.li> * Add files needed by the GHC build system A ./LICENSE A ./ghc-packages View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

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

21 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by Evi1M4chine): Replying to [comment:26 cjs]:[[br]] To be honest, I’m no fan or build systems. A compiler that doesn’t figure out dependencies and how to make a executable from it all for itself, is just deeply wrong in my eyes. This is essentially all you should ever ''have'' to do, no matter how the sources are structured: {{{ compile $allExternallyCompiledParts $allMySourceDirectories }}} (Of course what you ''could'' do, should include optimization, to what to compile it and code checking / debugging. But that should be it.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:27> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

21 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by cjs): Giving each target its own build directory works, but causes a lot of extra building when you have a lot of targets in a large system. E.g., in one recent major project I had perhaps a hundred source files and 20-30 targets (including test targets--only a dozen or so were production targets). Separate build dirs for each target would have turned a 5-10 minute full build into 2-3 hour full build. I was told the solution is to use libraries, but when you have test framework "main" targets within a number of library modules, that still doesn't fix the problem unless you also do do some interesting work on your build system to build a library and then a single module within that library separately that links to the rest of the library. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:26> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

21 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by Evi1M4chine): Replying to [comment:23 cjs]:[[BR]] I always thought of it like this: * The `--main-is` for a build target doesn’t change. * Every build target should have its own separate build directory. * If `--main-is` ''is'' changed, that invalidates the object file that was previously set as main, causing it to get deleted. * As early as possible, it is checked that there can always be just one module that has a program entry point. Those rules would prevent the problem, no? P.S.: Aren’t universal binaries executables with two program entry points, where the correct one for the arch is chosen by the OS? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:25> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

21 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by duncan): Thanks. Got it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:24> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #497: on package not found error: mention "cabal update"
by Hackage 21 Jun '11

21 Jun '11

#497: on package not found error: mention "cabal update" ----------------------------------+----------------------------------------- Reporter: Martijn | Owner: byorgey Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Comment(by kowey): I've attached a patch which I think takes care of the "no available version" case, albeit not in a particularly principled way... -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/497#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

21 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by cjs): Ah, sorry. Basically, different and incompatible object files are produced when you compile the same source with and without --main-is. Any object files compiled with --main-is cannot be linked into another program (that has its own main) because the two main functions will conflict at the link stage. Basically, the link stage doesn't know from main, it just links all the stuff together and depends on one (and only one) object file to have a program entry point (a "main") of some sort specified. This is a bit insidious because the object files go to the same location when compiled with or without --main-is. So if you do a clean build of some system with your --main-is set to one module, you will successfully link your final program. If you re-compile with the --main-is option reset, the GHC dependency checker (--make option) does not know that another module was previously compiled with --main-is, and when you hit the link stage you will get an error. Well, this is more or less how I remember it. If this still doesn't make sense, it's probably best to contact me via e-mail (cjs(a)cynic.net) and I can put together an example that demonstrates the problem more precisely, and give suggestions on how to have the build system deal with the issue (essentially, putting any object files compiled with --main-is in a separate object directory or just giving them different names). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:23> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

21 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by duncan): Replying to [comment:21 cjs]: > Do note, if you start implementing this for GHC, that if Blah.hs doesn't export main and is linked into other programs the versions of this with and without the main function must be compiled separately. (A typical case for this is where the main function is a test framework.) Sorry, I don't think I see what you're getting at. Could you try explaining it slower :-) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:22> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

20 Jun '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment(by cjs): That syntax works for me. Do note, if you start implementing this for GHC, that if Blah.hs doesn't export main and is linked into other programs the versions of this with and without the main function must be compiled separately. (A typical case for this is where the main function is a test framework.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:21> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0