Re: building a project with new-* commands
The build artefacts of new-* are placed in a "dist-newstyle" directory. Another common mistake with 1.24.0.0 is that `cabal new-build` won't do much at all if run in some parent directory. You might need to `cabal new-build ./my-blog/` and then get the artefacts somewhere (burried) in ./my-blog/dist-newstyle/... (I believe there is some improvement regarding behaviour in the parent directory in master already; certainly was planned.) Hope that helps. -- lennart On 16/09/16 13:40, Ramakrishnan Muthukrishnan wrote: > I have a fairly simple hakyll based blog website that I usually build > with cabal sandbox. > > Today I tried the new-configure/new-build commands. It built a bunch of > dependencies but the dist/build directory is empty. It doesn't look like > it built the project itself. Subsequent builds are fast as expected. But > I still don't see anything in dist/build directory. Am I missing > something or doing something silly? Not sure if this is the right list > to discuss "user" issues as this is a "devel" list. > > I created a new project with `cabal init' and built it with the new > style commands and it produced an executable in the expected place. > > The cabal-install/Cabal version I am running is 1.24.0.0 (for both) with > GHC 8.0.1 on Debian GNU/Linux x86-64. > > Thanks > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: pre-710 compatibility stuff
On 24/10/15 15:05, Thomas Tuegel wrote: > MIN_VERSION_base is defined by Cabal, so it is not available during > bootstrapping. This means we unfortunately need to use > __GLASGOW_HASKELL__ in Cabal, even though it isn't really the right > macro. It should be safe to use MIN_VERSION_base in cabal-install. ok, that makes sense, thanks Thomas and Herbert. Herbert also mentioned the qualified import trick to avoid CPP (the "more robust way" on [1]). While it is nifty, i am reluctant to apply it, given the silent/implicit requirement to have at least one reference to the qualified entity. Every contributor to such a module must be aware of this trick or risk accidentally breaking it. The explicitness of CPP seems preferable to me. [1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: inactive issues
I am not convinced. how does closing ~40 out of ~700 open tickets make the contributors more effective? that demand exceeds resources is true, but it is no argument for closing issues. many of the issues represent sensible ideas for features that do not need new feedback. I'd say the general lack of stability and the recently mentioned lack of tests are the main problems of Cabal; to a degree this looks like shooting at symptoms. But there is no need to convince me; there is need to priotize and my doubts are low priority at best. feel free to reply, but i'll try to shut up now :) Lennart On 25/02/15 08:09, Johan Tibell wrote: Good question. These issues were closed on my request. I've done similar clean-ups in the past. The issue tracker has gotten to large to be effective in help guide our work. We need to clean it up. In addition, lots of these issues weren't linked to the original reporter, making it less likely that the original reporter would step up with more information if needed, etc. On Tue, Feb 24, 2015 at 11:12 PM, Thomas Tuegel ttue...@gmail.com wrote: On Tue, Feb 24, 2015 at 3:52 PM, lennart spitzner l...@informatik.uni-kiel.de wrote: hi, i noticed today's run at the closing inactive issues on the tracker. i would like to to ask an innocent question: what exactly is the benefit of this action? (i disclose that it seems to me that valid, if inactive, issues are being closed, which i do not like. but before complaining, i want to know the counter-arguments). The most important reason is that we do not now, nor will we ever, have the human resources to fix all those issues. When we have done this before, we usually get a few people who chime in about an issue that still affects them. This allows us to prioritize on issues that cause actual developers actual problems. It also lets us find these issues; there are still valid issues back there, on Page 28 of our GitHub issue tracker, but I know I never venture back there. If an issue was closed that still causes you problems, you should by all means request that it be reopened. -- Thomas Tuegel ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
inactive issues
hi, i noticed today's run at the closing inactive issues on the tracker. i would like to to ask an innocent question: what exactly is the benefit of this action? (i disclose that it seems to me that valid, if inactive, issues are being closed, which i do not like. but before complaining, i want to know the counter-arguments). Lennart ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
improving commandline documentation/help
hello cabal devs, i am willing to put a bit of time into improving the help texts of cabal-install. some questions: 1) nobody else is working on this, right? is there risk that it interferes with other's work? (i'd basically touch Distribution.Simple.Command and the different fooCommand's in both Setup.hs's) 2) is there a specific reason that the help texts currently are so short, other than lack of time/focus on functionality? pending large changes or smth? 3) is there a policy to keep commits touching Cabal and cabal-install subdirectories separate (for git-subtree purposes, for example)? Lennart ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
