How to generate one stack project for both mac and linux?

[philderbeast]

I tried cabal2stack and found it generates different stack files on linux and mac for one project. There is only a very few differences but one is the same as I found in this closely-related thread about cabal freeze files:

- "hinotify-0.4.1"
+ "hfsevents-0.1.6"

This is cabal's doing isn't it when it chooses a plan? Is there no way around this that would enable creating a stack project that would work on both linux and mac?

[philderbeast]

It doesn't take much to get the generated stack project building without platform-specific stuff in it; 1) remove the fsnotify-related stuff and 2) change the resolver:

- "enclosed-exceptions-1.0.3"
- "fsnotify-0.3.0.1"
- "hinotify-0.4.1"
- "shelly-1.9.0"
-   shelly:
-    "build-examples": false
-    lifted: false
- resolver: "ghc-8.10.7"
+ resolver: lts-18.27

With these changes of the stack project generated with cabal2stack on linux I can still build on linux and can build on mac when I couldn't before.

[adamgundry]

Hmm, the general problem here seems tricky. I don't know if stack.yaml has a mechanism to specify different dependencies based on OS? But since cabal2stack starts with a build plan on one particular system, it's then hard to determine which dependencies might be platform-dependent.

Explicitly specifying the resolver being used certainly shouldn't hurt. I guess in this case that is enough because the resolver includes the right OS-specific packages/flags, so they can then safely be omitted from the stack.yaml file?

Ideally I think it would be nice to drop "redundant" entries in the stack.yaml based on diffing the build plan against the resolver's versions. But that would require retrieving the contents of the specific resolver.

[philderbeast]

Ideally I think it would be nice to drop "redundant" entries in the stack.yaml based on diffing the build plan against the resolver's versions. But that would require retrieving the contents of the specific resolver.

That would be nice to have.

For the resolver's versions in cabal.config format, we could:

• Supply this ourselves via stdin:

curl --silent https://www.stackage.org/lts-18.27/cabal.config | cabal2stack --config-stdin

• Have cabal2stack look in the well known places:
  • lts-18.27 => https://www.stackage.org/lts-18.27/cabal.config
  • nightly-2022-11-12 => https://www.stackage.org/nightly-2022-11-12/cabal.config

After generating a cabal2stack-generated.yaml, stack can give us dependencies:

• In cabal.config format with the new (and unreleased) ls dependencies cabal command:

> stack --stack-yaml=cabal2sack-generated.yaml ls dependencies cabal
constraints:
  , HTTP ==4000.3.16
  , HUnit ==1.6.2.0
...

• In stack.yaml format with:

> stack --stack-yaml=cabal2stack-generated.yaml ls dependencies text --separator "-"
HTTP-4000.3.16
HUnit-1.6.2.0
...

A cabal.config mentions the resolver in a header comment.

-- NOTE: Due to revisions, this file may not work. See:
-- https://github.com/fpco/stackage-server/issues/232

-- Stackage snapshot from: http://www.stackage.org/snapshot/lts-18.27
-- Please place this file next to your .cabal file as cabal.config
-- To only use tested packages, uncomment the following line:
-- remote-repo: stackage-lts-18.27:http://www.stackage.org/lts-18.27
with-compiler: ghc-8.10.7
constraints: abstract-deque ==0.3,
             abstract-par ==0.3.3,
             AC-Angle ==1.0,