- cabal-devel - Haskell.org

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

23 Mar '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 ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix Comment: The file name does not need to be Main.hs, it can be any name.hs that you like. The reason we do not support `-main-is` is because it is a ghc-specific extension that does not work for other Haskell implementations. Your example is easy to deal with. If you want one module with two targets, define both targets in one module, then have two other 2-line .hs files to be the main modules, e.g.: Ozon.hs: {{{ ozon = ... tests = ... }}} main.hs: {{{ import Ozon main = ozon }}} tests.hs: {{{ import Ozon main = teste }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:13> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

23 Mar '11

#179: support GHC's main-is extension ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------+----------------------------------------------- Comment(by Evi1M4chine): Hey, I just noticed the same problem, and I think it’s weird to force the main function to be “main” in the module “Main”. First of all, because most people in the world don’t prefer English as it isn’t their native language, and secondly because the main module, main function and main file name should 1. be the same and 2. be the name of your project. I have a program called “Ozon”, which has to build targets: Programm: ghc -threaded -static -O2 -fPIC -Wall -Wwarn -outputdir bauen -fglasgow-exts -iquellen -main-is Ozon.ozon -o ozon --make quellen/Ozon.hs Test: ghc -threaded -static -debug -O0 -fPIC -Wall -Wwarn -outputdir bauen -fglasgow-exts -iquellen -main-is Ozon.teste -o teste --make quellen/Ozon.hs As you can see, the main module (Ozon) in the main file (Ozon.hs) has *two* main functions. One for each mode/target. With Cabal, it’s not possible do do this, and you’re forced to make a mess out of it, by inconsistently naming things and splitting up files that shouldn’t be split up. Even enforcing “-main-is" in “ghc-options:” is not working with two build targets. (Unless leksah 0.8.0.8 generates the cabal file wrongly, but I don’t think so.) The second one is simply ignored, and both resulting binaries are exactly the same. It would be enough, if those ghc-options would work properly. But of course, main-is should be renamed main-file-is, and a main-function-is should be added. (The main module name can be automatically deduced from the “module” statement in the main file.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Parallel Build Logging
by Frank Murphy 22 Mar '11

22 Mar '11

On http://hackage.haskell.org/trac/hackage/ticket/447, it's suggested that during parallel builds the output from child jobs simply shouldn't be displayed at all. When it comes to dealing with concurrent logging, why not have children write all log lines via queue to a master thread, then have the master flush all output associated with a job once it completes? That way the user can still see a "sequential" build, it will just seem to progress faster. P.S. If I should post questions like this on the associated task let me know. Thanks, Frank

1 0

[Hackage] #819: Pass extra parameters of 'configure' to user hooks
by Hackage 22 Mar '11

22 Mar '11

#819: Pass extra parameters of 'configure' to user hooks ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: configure, command Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Non-standard options to 'configure' are not supported by Cabal; to accept new options requires writing a custom version of Cabal's 'defaultMain'. It would be useful to provide some support for extending the command-line parser, or at least passing unrecognized arguments to user hooks. To motivate this feature, here's my use case. During the build phase, my package builds an executable, then uses the executable to build some data files. The executable and data files are installed together. If the executable needs extra arguments (e.g., search paths) to run, they can be supplied as command-line parameters to 'configure'. Supporting these extra parameters required some changes to Cabal. I did it by copying 'defaultMainWithHooks' and some 200-odd lines of non- exported functions from Distribution.Simple into my package's Setup.hs so that I could override 'configureCommand'. This gave me access to the command-line parser. Relatively little code was actually changed, so hopefully this feature would fit nicely into the current codebase. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/819> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Cabal API: getting the online package list
by Frank Murphy 22 Mar '11

22 Mar '11

I was poking around the source for cabal-install while investigating a (hopeful) GSoC product. One thing seems a little odd to me: is there a reason that, for example, getAvailablePackages isn't in a separate library? Or is similar functionality in a different package than Cabal already and I just haven't found it (doing a search for "cabal" on Hackage didn't appear to turn up anything)? For context, I'm trying to build a graph of install dependencies for an (uninstalled) package. Thanks, Frank

2 1

[Hackage] #790: Make cabal check warn if copyright field doesn't have current year
by Hackage 19 Mar '11

19 Mar '11

#790: Make cabal check warn if copyright field doesn't have current year ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Quite a few packages being uploaded on Hackage have 2010 as the copyright year, probably because developers forgot to update the year. As an example, see http://hackage.haskell.org/package/turni-2011.1.15 which was uploaded in 2011, but puts the copyright as 2010 (that's just the first I encountered, but there are loads). I suggest cabal check should warn if copyright doesn't have the current year in the field. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/790> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #816: c-sources get passed to GHC instead of gcc
by Hackage 17 Mar '11

17 Mar '11

#816: c-sources get passed to GHC instead of gcc ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I realize this may be hard to fix and only rarely a problem, but I think it's worth creating a ticket to track it. Files specified as c-sources are handed to GHC instead of gcc. This is normally fine, but there are times when a file that gcc could handle is rejected by GHC. For example, .m files are rejected by GHC because it thinks they are linker scripts but gcc accepts them as objective-c. See for example this ticket: http://hackage.haskell.org/trac/ghc/ticket/5025 It's not a common problem, but when you do bump into it, it's a HUGE pain to work around and leaves you as a user with a sense of being artificially limited by your build system. The pain is exacerbated because the work around seems to require that you: * Build the c-sources that GHC won't accept using some other means, say a makefile, and build it into libfoo.a * Switch to Build-type: Custom * Then you have to modify Setup.hs to call your makefile during an early step such as preConf * Then you need copy and postInst steps that put libfoo.a in a place where it can be found when building things that depend on your package. * With newer GHCs you need to add --force during the package registration because the "extra" library will technically have a relative path and ghc-pkg doesn't like this (for a good reason, I assume). * 'cabal sdist' will complain unless you are careful (read: sneaky). All of the above can be done, but it's a lot of work for something that could be very simple. For a working example see this package: http://hackage.haskell.org/package/GLFW-b-0.0.2.3 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/816> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #229: Build C sources using the system's C compiler directly
by Hackage 17 Mar '11

17 Mar '11

#229: Build C sources using the system's C compiler directly -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- Changes (by duncan): * cc: dagitj@… (added) Comment: See also ticket #816 on the difficulties caused. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/229#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #200: Allow more convenient use of ghc profiling options -auto and -auto-all
by Hackage 16 Mar '11

16 Mar '11

#200: Allow more convenient use of ghc profiling options -auto and -auto-all ------------------------------+--------------------------------------------- Reporter: guest | Owner: kmcallister Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: patch Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- Changes (by ezyang): * keywords: => patch -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/200#comment:13> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #411: Command to install dependencies of a package.
by Hackage 15 Mar '11

15 Mar '11

#411: Command to install dependencies of a package. ---------------------------------+------------------------------------------ Reporter: mornfall | Owner: Type: defect | Status: closed Priority: normal | Milestone: cabal-install-0.10 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: ---------------------------------+------------------------------------------ Changes (by duncan): * status: new => closed * resolution: => fixed * milestone: cabal-install-0.8 => cabal-install-0.10 Comment: This feature is now implemented in cabal-install-0.10. Use: {{{ cabal install blah --only-dependencies }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/411#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0