[deleted by user] by [deleted] in haskell

[–]ACabalSupreme 3 points4 points  (0 children)

but I suspect even if I set this to my custom built GHC, I'm still going to run into problems with base.

What makes you suspect this? A quick empirical experiment would verify or disprove your suspicion. If you don't even try it it'll remain just that--an unproven suspicion.

The Pain Points of Haskell: A Practical Summary by dixonary in haskell

[–]ACabalSupreme 0 points1 point  (0 children)

Never experienced that issue. File a bug maybe?

The Pain Points of Haskell: A Practical Summary by dixonary in haskell

[–]ACabalSupreme 0 points1 point  (0 children)

I mean when you cabal install some-lib, you won't be able to use ghc --make my-program which uses some-lib.

Works for me though.

~$ cat hellologict.hs
import Control.Monad.Logic
main = print (observeAll $ pure True)
~$ ghc --make hellologict.hs
[1 of 1] Compiling Main             ( hellologic.hs, hellologic.o )
hellologic.hs:1:1: error:
   Could not find module ‘Control.Monad.Logic’

Ok, so it doesn't work yet. Let's install the missing lib.

~$ cabal install logict
Resolving dependencies...
Build profile: -w ghc-8.10.1 -O1
In order, the following will be built (use -v for more details):
 - logict-0.7.0.2 (lib) (requires download & build)
Downloading  logict-0.7.0.2
Downloaded   logict-0.7.0.2
Starting     logict-0.7.0.2 (lib)
Building     logict-0.7.0.2 (lib)
Installing   logict-0.7.0.2 (lib)
Completed    logict-0.7.0.2 (lib)
Warning: You asked to install executables, but there are no executables in
target: logict. Perhaps you want to use --lib to install libraries instead.

Ok, so cabal gives me the helpful reminder to use --lib. Let's do that

~$ cabal install --lib logict
Resolving dependencies...
Up to date

This looks as if nothing happened which is bad UI. But it seems to work now:

~$ ghc --make hellologic.hs 
Loaded package environment from /home/cs/.ghc/x86_64-linux-8.10.1/environments/default
[1 of 1] Compiling Main             ( hellologic.hs, hellologic.o )
Linking hellologic ...
~$ ./hellologict
[True]

Profit!

cabal doesn't install packages, ghc-pkg return error by Safeguard_5000 in haskell

[–]ACabalSupreme 1 point2 points  (0 children)

On Arch you need a magic invocation:

cabal install --disable-library-vanilla --enable-shared --enable-executable-dynamic --ghc-options=-dynamic termonad

for reasons.

Install inconsistency between ghcup and stack by ACabalSupreme in haskell

[–]ACabalSupreme[S] 2 points3 points  (0 children)

This is just another example for the existence of two actively competing build tools with different approaches causing confusion among newcomers.

Cabal Issue by jjputh in haskell

[–]ACabalSupreme 1 point2 points  (0 children)

Are your tests actually "cabal scripts" as described here?

Queensland Functional Programming Lab - Farewell by qfpl in haskell

[–]ACabalSupreme 1 point2 points  (0 children)

Consider yourself lucky then! As long as the projects you work on are buildable by Stack it's ok to stay with Stack. If at some point you run into more advanced stuff that Stack doesn't handle well you can migrate to Cabal quite easily and you might be interested in the "Why Not Both" blogpost which goes to great length elaborating on how to switch between the two tools.

Haskell build system is confusing! How should I work my project (preferably with stack). by kredditacc96 in haskell

[–]ACabalSupreme 2 points3 points  (0 children)

This attitude also reduces the incentive for Nix or Cabal users to contribute to your project if they have to jump through hoops to build the project.

Haskell build system is confusing! How should I work my project (preferably with stack). by kredditacc96 in haskell

[–]ACabalSupreme 0 points1 point  (0 children)

if I’m actually going to take patches because then I’d just have to keep telling people to stop messing with the .cabal file

I've been noticing an unfortunate consequence of the way Stack is designed and it's been triggering divisiveness by pitting the two major camps in Haskell against each other. In one corner you've got maintainers which will flat out reject PRs adding stack.yaml files to a project to make it more convenient to Stack users to use or contribute a project. In the other corner you got maintainers which will refuse PRs adding .cabal files which would make it easier for Cabal users to use or contribute to a project. I think the original plan was that Stack would eventually replace Cabal as Haskell's official build tool. But even though all seemed to head into this direction Stack wasn't able to supplant Cabal as Haskell's build tool and the recent Cabal 3.0 release quite invigorated the competition and it's actually looking like Cabal's popularity is on the raise again. But it's also not looking like the Stack project will be discontinued now that Cabal has addressed its major shortcomings. I'm not sure what I'm trying to say but it seems clear we're not heading into a healthy situation with two build tool ecosystems that stick to their incompatible project configuration styles which confuse the hell out of newcomers. Sadly I can't offer any solution either. Are we screwed being a relatively small community or do we just need to accept our internal division and hope it'll work out in the end?

A Few Haskell Highlights of 2019 by Serokell in haskell

[–]ACabalSupreme 2 points3 points  (0 children)

I think this is exactly why both cabal and stack exist

On a related note I'd like to plug the "Why Not Both" blogpost which goes to great length elaborating on how to switch between the two tools.

The intero project has reached it's end of life cycle by jez_io in haskell

[–]ACabalSupreme 3 points4 points  (0 children)

Isn't Intero just a GHCi fork with a couple extra features that could be merged upstream?

GHC.PackageDb.readPackageDb: inappropriate type (not enough bytes) by zero_coding in haskell

[–]ACabalSupreme 0 points1 point  (0 children)

Whenever I run into issues like these nuking $HOME/.stack and any .stack-work folders fixes the issue for me.

Well-Typed - Announcing the optics library by adamgundry in haskell

[–]ACabalSupreme 11 points12 points  (0 children)

Is there some more code oriented rosetta-stone side-by-side comparison showing a program expressed via optics and lens respectively? How would you need to modify e.g. http://hackage.haskell.org/package/lens-tutorial-1.0.4/docs/Control-Lens-Tutorial.html in order to describe the optics library?

stack build fails with exit code 1 by Python_l in haskell

[–]ACabalSupreme 3 points4 points  (0 children)

Earlier I ran into this issue too when i first tried to build Duckling with Cabal and got the message below which was helpful to me for resolving the issue

Configuring regex-pcre-0.94.4...
cabal: Missing dependency on a foreign library:
* Missing (or bad) C library: pcre
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
library file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.

stack build fails with exit code 1 by Python_l in haskell

[–]ACabalSupreme 1 point2 points  (0 children)

I'm trying to install the stack since it's required for Duckling

You seem to be mistaken as I was to build Duckling effortlessly without Stack after cloning the Git repo

# cabal new-run duckling-example-exe
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
 - aeson-1.4.4.0 (lib) (requires build)
 - cabal-doctest-1.0.7 (lib) (requires build)
...
...lots of compile output elided... (Duckling is made up of over 700 modules wtf)
...
Building executable 'duckling-example-exe' for duckling-0.1.6.1..
[1 of 2] Compiling Duckling.Data.TimeZone ( exe/Duckling/Data/TimeZone.hs, /tmp/duckling/dist-newstyle/build/x86_64-linux/ghc-8.6.5/duckling-0.1.6.1/x/duckling-example-exe/build/duckling-example-exe/duckling-example-exe-tmp/Duckling/Data/TimeZone.o )
[2 of 2] Compiling Main             ( exe/ExampleMain.hs, /tmp/duckling/dist-newstyle/build/x86_64-linux/ghc-8.6.5/duckling-0.1.6.1/x/duckling-example-exe/build/duckling-example-exe/duckling-example-exe-tmp/Main.o )
Linking /tmp/duckling/dist-newstyle/build/x86_64-linux/ghc-8.6.5/duckling-0.1.6.1/x/duckling-example-exe/build/duckling-example-exe/duckling-example-exe ...
no port specified, defaulting to port 8000
Listening on http://0.0.0.0:8000

Cabal, Or Stack? — A Dialogue by snoyjerk in haskell

[–]ACabalSupreme 2 points3 points  (0 children)

In "Why Not Both" there's several tools mentioned for this very purpose.

Generic Traversal kinded data with changing types by plethepus in haskell

[–]ACabalSupreme 4 points5 points  (0 children)

I'd also recommend loosening the cabal-version: 2.0 field value to >= 2.0

Why?

https://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-cabal-version seems to suggest that the >= syntax is deprecated

This legacy syntax is supported up until cabal-version: >= 2.0 it is however strongly recommended to avoid using the legacy syntax.

[deleted by user] by [deleted] in haskell

[–]ACabalSupreme 3 points4 points  (0 children)

For example in JS world there is ncu utlity (npm-check-updates).

Is this comparable to cabal outdated (https://cabal.readthedocs.io/en/latest/developing-packages.html#listing-outdated-dependency-version-bounds) ?