From edwards.benj at gmail.com Mon Dec 2 20:37:09 2013 From: edwards.benj at gmail.com (Benjamin Edwards) Date: Mon, 2 Dec 2013 20:37:09 +0000 Subject: Get all the processed sources for a cabal project Message-ID: Hi, I want to make a nice tags generator for vim that plays well with cabal sandboxes. I was wondering if there was a way to make cabal cough up all the source files for a sandboxed project taking into account the current configuration (i.e. after flags and the cpp pre-processor has been applied). If not, could anyone point me to where to look to start figuring out how to make it happen? Best, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Dec 4 09:36:56 2013 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 4 Dec 2013 10:36:56 +0100 Subject: Get all the processed sources for a cabal project In-Reply-To: References: Message-ID: I don't know of anything taking into account the current configuration. There is cabal sdist --list-sources, which will list all the files that would be written to a source distribution. Alternatively, there is the output from 'ghc -M', which generates dependencies in Makefile format. Neither quite does what you want, but perhaps you can use it anyway. Alternatively, you could try using the Cabal library to do what you want. Regards, Erik On Mon, Dec 2, 2013 at 9:37 PM, Benjamin Edwards wrote: > Hi, > > I want to make a nice tags generator for vim that plays well with cabal > sandboxes. I was wondering if there was a way to make cabal cough up all the > source files for a sandboxed project taking into account the current > configuration (i.e. after flags and the cpp pre-processor has been applied). > > If not, could anyone point me to where to look to start figuring out how to > make it happen? > > Best, > Ben > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > From selinger at mathstat.dal.ca Sun Dec 8 18:50:21 2013 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Sun, 8 Dec 2013 14:50:21 -0400 (AST) Subject: cabal: question on compiling build prerequisites In-Reply-To: Message-ID: <20131208195523.0A1898C017C@chase.mathstat.dal.ca> Hi John, thanks for your reply! So say my package directory contains two files: Test.hs PreProc.hs What you are suggesting is: ghc Test.hs -F -pgmF ./PreProc However, this gives the error message: ghc: could not execute: ./PreProc And indeed, while GHC is smart enough to automatically run a preprocessor, it is not smart enough to automatically *compile* the preprocessor. So it needs to be compiled beforehand, which would be Cabal's job. But strangely, there doesn't seem to be a way to get Cabal to do this (apart from doing some very low-level hacking in the Setup.hs file). Hence my question. In a related problem, and more generally, the .cabal format seems to be lacking any way to specify things (packages, built programs) that are prerequisites of Setup.hs, as opposed to of the libraries or executables being built. So if my Setup.hs imports some non-base package, there is no way to ensure it is actually installed before Setup.hs is compiled or run. I'm ccing this to the cabal-devel list, because it's apparently a more appropriate place to discuss this than libraries at haskell.org. Thanks, -- Peter John Lato wrote: > > Ghc has a flag -pgmF that you can use for this. You'd need to include your > preprocessor source in the extra-source-files field of build-depends. In > this case cabal won't know anything about the preprocessor, ghc will run it > directly. > On Dec 6, 2013 7:31 PM, "Peter Selinger" wrote: > > > This may be a silly question, but I can't seem to find the answer in > > the documentation. > > > > I would like to create a Cabal package where some of the source files > > use a custom pre-processor. The pre-processor is itself a Haskell > > program, let's say MyPreProc.hs in the package's root directory. > > > > I figured out how to activate the preprocessor, for example, > > > > cabal build --ghc-options="-F -pgmF ./MyPreProc" > > > > I also figured out how to achieve the same effect using hooks. > > > > However, there is one problem: how can I tell cabal to actually > > compile MyPreProc.hs before any of the commands using the preprocessor > > are run? The package's Setup.hs file is automatically compiled during > > "cabal configure". I would like MyPreProc.hs to be compiled at the > > same time as well - or at least some time before the proprocessor > > needs to be used. > > > > The .cabal file contains all kinds of related variables, such as > > "build-depends" (but only packages can be listed here, not programs to > > be compiled), "other-modules" (but these modules would already require > > the pre-processor, so the pre-processor should be compiled first), > > "build-tools" (but this only refers to external programs). > > > > My current solution is to make the pre-processor a shell script, > > rather than a Haskell program. But this is ugly and not portable > > (won't work in Windows, for example). > > > > To clarify: my custom preprocessor is local to this package. It has no > > independent value, so it would not make sense to publish it as a > > separate package just so that I can add it to build-depends. > > > > Is there a known solution to this problem? > > > > Thanks, -- Peter > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > From hesselink at gmail.com Sun Dec 8 20:37:33 2013 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 8 Dec 2013 21:37:33 +0100 Subject: cabal: question on compiling build prerequisites In-Reply-To: <20131208195523.0A1898C017C@chase.mathstat.dal.ca> References: <20131208195523.0A1898C017C@chase.mathstat.dal.ca> Message-ID: On Sun, Dec 8, 2013 at 7:50 PM, Peter Selinger wrote: > thanks for your reply! So say my package directory contains two files: > > Test.hs > PreProc.hs > > What you are suggesting is: > > ghc Test.hs -F -pgmF ./PreProc > > However, this gives the error message: > > ghc: could not execute: ./PreProc > > And indeed, while GHC is smart enough to automatically run a > preprocessor, it is not smart enough to automatically *compile* the > preprocessor. So it needs to be compiled beforehand, which would be > Cabal's job. Not per se. You could try making it executable, and prepending a line like: #!/usr/bin/env runhaskell That way you can run your preprocessor like a script, without compiling it. Erik From selinger at mathstat.dal.ca Sun Dec 8 23:48:51 2013 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Sun, 8 Dec 2013 19:48:51 -0400 (AST) Subject: cabal: question on compiling build prerequisites In-Reply-To: Message-ID: <20131208234851.5CFA78C017E@chase.mathstat.dal.ca> Thanks for the suggestion! However, it is not portable: it doesn't work on Windows. Similarly, giving "runhaskell ./PreProc.hs" as the preprocessor command to GHC doesn't work either, because GHC will try to run a program with that exact name (including the space), rather than interpreting it as a command with an argument. In addition, even on Posix systems, where the above method does work, it is nevertheless extremely slow: runhaskell will have to interpret or compile ./PreProc.hs separately for each source file, of which there could be many. Another solution I thought of is to include import Preproc at the beginning of Setup.hs. This way compiling Setup.hs would have the side effect of compiling Preproc.hs. It would not work with the "runhaskell Setup.hs" method, though. -- Peter Erik Hesselink wrote: > > On Sun, Dec 8, 2013 at 7:50 PM, Peter Selinger wrote: > > thanks for your reply! So say my package directory contains two files: > > > > Test.hs > > PreProc.hs > > > > What you are suggesting is: > > > > ghc Test.hs -F -pgmF ./PreProc > > > > However, this gives the error message: > > > > ghc: could not execute: ./PreProc > > > > And indeed, while GHC is smart enough to automatically run a > > preprocessor, it is not smart enough to automatically *compile* the > > preprocessor. So it needs to be compiled beforehand, which would be > > Cabal's job. > > Not per se. You could try making it executable, and prepending a line like: > > #!/usr/bin/env runhaskell > > That way you can run your preprocessor like a script, without compiling it. > > Erik > From dag.odenhall at gmail.com Thu Dec 12 18:21:39 2013 From: dag.odenhall at gmail.com (Dag Odenhall) Date: Thu, 12 Dec 2013 19:21:39 +0100 Subject: cabal: question on compiling build prerequisites In-Reply-To: <20131208234851.5CFA78C017E@chase.mathstat.dal.ca> References: <20131208234851.5CFA78C017E@chase.mathstat.dal.ca> Message-ID: How about -pgmF runghc -optF PreProc? On Mon, Dec 9, 2013 at 12:48 AM, Peter Selinger wrote: > Thanks for the suggestion! However, it is not portable: it doesn't > work on Windows. > > Similarly, giving "runhaskell ./PreProc.hs" as the preprocessor > command to GHC doesn't work either, because GHC will try to run a > program with that exact name (including the space), rather than > interpreting it as a command with an argument. > > In addition, even on Posix systems, where the above method does work, > it is nevertheless extremely slow: runhaskell will have to interpret > or compile ./PreProc.hs separately for each source file, of which > there could be many. > > Another solution I thought of is to include > > import Preproc > > at the beginning of Setup.hs. This way compiling Setup.hs would have > the side effect of compiling Preproc.hs. It would not work with the > "runhaskell Setup.hs" method, though. > > -- Peter > > Erik Hesselink wrote: > > > > On Sun, Dec 8, 2013 at 7:50 PM, Peter Selinger > wrote: > > > thanks for your reply! So say my package directory contains two files: > > > > > > Test.hs > > > PreProc.hs > > > > > > What you are suggesting is: > > > > > > ghc Test.hs -F -pgmF ./PreProc > > > > > > However, this gives the error message: > > > > > > ghc: could not execute: ./PreProc > > > > > > And indeed, while GHC is smart enough to automatically run a > > > preprocessor, it is not smart enough to automatically *compile* the > > > preprocessor. So it needs to be compiled beforehand, which would be > > > Cabal's job. > > > > Not per se. You could try making it executable, and prepending a line > like: > > > > #!/usr/bin/env runhaskell > > > > That way you can run your preprocessor like a script, without compiling > it. > > > > Erik > > > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinger at mathstat.dal.ca Thu Dec 12 19:19:36 2013 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Thu, 12 Dec 2013 15:19:36 -0400 (AST) Subject: cabal: question on compiling build prerequisites In-Reply-To: Message-ID: <20131212191936.96F4A8C017C@chase.mathstat.dal.ca> That is a good point. I'll try it. -- Peter Dag Odenhall wrote: > > How about -pgmF runghc -optF PreProc? > > > On Mon, Dec 9, 2013 at 12:48 AM, Peter Selinger wrote: > > > Thanks for the suggestion! However, it is not portable: it doesn't > > work on Windows. > > > > Similarly, giving "runhaskell ./PreProc.hs" as the preprocessor > > command to GHC doesn't work either, because GHC will try to run a > > program with that exact name (including the space), rather than > > interpreting it as a command with an argument. > > > > In addition, even on Posix systems, where the above method does work, > > it is nevertheless extremely slow: runhaskell will have to interpret > > or compile ./PreProc.hs separately for each source file, of which > > there could be many. > > > > Another solution I thought of is to include > > > > import Preproc > > > > at the beginning of Setup.hs. This way compiling Setup.hs would have > > the side effect of compiling Preproc.hs. It would not work with the > > "runhaskell Setup.hs" method, though. > > > > -- Peter > > > > Erik Hesselink wrote: > > > > > > On Sun, Dec 8, 2013 at 7:50 PM, Peter Selinger > > wrote: > > > > thanks for your reply! So say my package directory contains two files: > > > > > > > > Test.hs > > > > PreProc.hs > > > > > > > > What you are suggesting is: > > > > > > > > ghc Test.hs -F -pgmF ./PreProc > > > > > > > > However, this gives the error message: > > > > > > > > ghc: could not execute: ./PreProc > > > > > > > > And indeed, while GHC is smart enough to automatically run a > > > > preprocessor, it is not smart enough to automatically *compile* the > > > > preprocessor. So it needs to be compiled beforehand, which would be > > > > Cabal's job. > > > > > > Not per se. You could try making it executable, and prepending a line > > like: > > > > > > #!/usr/bin/env runhaskell > > > > > > That way you can run your preprocessor like a script, without compiling > > it. > > > > > > Erik > > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel > > From selinger at mathstat.dal.ca Sat Dec 14 06:06:54 2013 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Sat, 14 Dec 2013 02:06:54 -0400 (AST) Subject: cabal: question on compiling build prerequisites In-Reply-To: Message-ID: <20131214060655.32FBA8C017C@chase.mathstat.dal.ca> Hi Dag, this was a good suggestion, but it doesn't work. When invoking this preprocessor, GHC will run the command runghc PreProc. In other words, any options specified with -optF are appended at the *end* of the preprocessor arguments, not the beginning. So one can never use runghc to run a proprocessor. Thanks, -- Peter Dag Odenhall wrote: > > How about -pgmF runghc -optF PreProc? > > > On Mon, Dec 9, 2013 at 12:48 AM, Peter Selinger wrote: > > > Thanks for the suggestion! However, it is not portable: it doesn't > > work on Windows. > > > > Similarly, giving "runhaskell ./PreProc.hs" as the preprocessor > > command to GHC doesn't work either, because GHC will try to run a > > program with that exact name (including the space), rather than > > interpreting it as a command with an argument. > > > > In addition, even on Posix systems, where the above method does work, > > it is nevertheless extremely slow: runhaskell will have to interpret > > or compile ./PreProc.hs separately for each source file, of which > > there could be many. > > > > Another solution I thought of is to include > > > > import Preproc > > > > at the beginning of Setup.hs. This way compiling Setup.hs would have > > the side effect of compiling Preproc.hs. It would not work with the > > "runhaskell Setup.hs" method, though. > > > > -- Peter > > > > Erik Hesselink wrote: > > > > > > On Sun, Dec 8, 2013 at 7:50 PM, Peter Selinger > > wrote: > > > > thanks for your reply! So say my package directory contains two files: > > > > > > > > Test.hs > > > > PreProc.hs > > > > > > > > What you are suggesting is: > > > > > > > > ghc Test.hs -F -pgmF ./PreProc > > > > > > > > However, this gives the error message: > > > > > > > > ghc: could not execute: ./PreProc > > > > > > > > And indeed, while GHC is smart enough to automatically run a > > > > preprocessor, it is not smart enough to automatically *compile* the > > > > preprocessor. So it needs to be compiled beforehand, which would be > > > > Cabal's job. > > > > > > Not per se. You could try making it executable, and prepending a line > > like: > > > > > > #!/usr/bin/env runhaskell > > > > > > That way you can run your preprocessor like a script, without compiling > > it. > > > > > > Erik > > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel > > > From simons at cryp.to Mon Dec 16 15:34:36 2013 From: simons at cryp.to (Peter Simons) Date: Mon, 16 Dec 2013 16:34:36 +0100 Subject: -Werror flag for Cabal? Message-ID: <87wqj4lshf.fsf@write-only.here.com> Hi guys, is there any way to turn the following configure-time warning into a fatal error? Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. Best regards, Peter From johan.tibell at gmail.com Thu Dec 19 11:42:00 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 19 Dec 2013 12:42:00 +0100 Subject: Should we aim for a new release in late January? In-Reply-To: References: Message-ID: I was thinking that I might get most of the release work ready before my holidays end on January 5th. That would make the release 1.20 release come out 3 months after the 1.18; a quite nice release pace. There are a bunch of outstanding pull requests here: https://github.com/haskell/cabal/pulls It would be nice if we could make an effort to either shepherd these through or close them. Any major outstanding bugs that need to be fixed before the release? -- Johan On Wed, Nov 27, 2013 at 10:01 PM, Johan Tibell wrote: > Hi, > > Cabal development is continuing at a furious pace. There are lots of great > things in master that I'd like to get out to users, such as > > * relinking avoidance > * build -j > * ability to specify exact deps on the command line > * haskell-suite compiler support > * bug fixes > > Here's an approximate list of commits (both Cabal and cabal-install) since > the last release: > > https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master > > It's not entirely accurate as some patches were cherry-picked onto the > 1.18 branch and thus have different commit IDs. > > -- Johan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Thu Dec 19 13:02:08 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 19 Dec 2013 14:02:08 +0100 Subject: Should we aim for a new release in late January? In-Reply-To: References: Message-ID: Hi Johan, On Thu, Dec 19, 2013 at 12:42 PM, Johan Tibell wrote: > [...] > Any major outstanding bugs that need to be fixed before the release? No, I don't think so. I'm using HEAD and it works absolutely fine. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments