For windowsintegersimple resolve flags as if Windows OS

[3noch]

I have very little confidence I did this right, but here's my good faith effort. :)

See #399

[3noch]

GHC 7.10.1 builds but with xz compression:

• 32-bit
• 64-bit

[3noch]

I'm out for the holiday weekend, so do whatever you wish to this in the meantime. I'll be back Monday.

[3noch]

I think there's still something afoot. I wonder if there's a Cabal version mismatch, but my builds are failing. More details next week if you don't beat me to it.

[3noch]

FWIW:

--  While building package unordered-containers-0.2.5.1 using:
      C:\\Users\\Elliot Cameron\\AppData\\Roaming\\stack\\programs\\i386-windowsintegersimple\\ghc-7.10.1\\bin\\runhaskell.exe -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package-db=C:\Users\Elliot Cameron\AppData\Roaming\stack\snapshots\i386-windowsintegersimple\nightly-2015-07-02\7.10.1\pkgdb\ C:\Users\ELLIOT~1\AppData\Local\Temp\stack14932\Setup.hs --builddir=.stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\ build
    Process exited with code: ExitFailure 1
    Logs have been written to: "C:\\Code\\windows-client\\.stack-work\\logs\\unordered-containers-0.2.5.1.log"

    Configuring unordered-containers-0.2.5.1...
    Building unordered-containers-0.2.5.1...
    Preprocessing library unordered-containers-0.2.5.1...
    [1 of 8] Compiling Data.HashMap.UnsafeShift ( Data\HashMap\UnsafeShift.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashMap\UnsafeShift.o )
    [2 of 8] Compiling Data.HashMap.PopCount ( Data\HashMap\PopCount.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashMap\PopCount.o )
    [3 of 8] Compiling Data.HashMap.Unsafe ( Data\HashMap\Unsafe.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashMap\Unsafe.o )
    [4 of 8] Compiling Data.HashMap.Array ( Data\HashMap\Array.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashMap\Array.o )
    [5 of 8] Compiling Data.HashMap.Base ( Data\HashMap\Base.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashMap\Base.o )

    Data\HashMap\Base.hs:85:1: Warning:
        The import of `Data.Functor' is redundant
          except perhaps to import instances from `Data.Functor'
        To import instances alone, use: import Data.Functor()
    [6 of 8] Compiling Data.HashMap.Strict ( Data\HashMap\Strict.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashMap\Strict.o )
    [7 of 8] Compiling Data.HashMap.Lazy ( Data\HashMap\Lazy.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashMap\Lazy.o )
    [8 of 8] Compiling Data.HashSet     ( Data\HashSet.hs, .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\Data\HashSet.o )
    C:\Users\Elliot Cameron\AppData\Roaming\stack\programs\i386-windowsintegersimple\ghc-7.10.1\mingw\bin\ar.exe: .stack-work\dist\i386-windowsintegersimple\Cabal-1.22.2.0\build\libHSunordered-containers-0.2.5.1-AP0g8NmrBD35Ls9w1ZDHH1.a-13844\libHSunordered-containers-0.2.5.1-AP0g8NmrBD35Ls9w1ZDHH1.a: No such file or directory

[3noch]

Also, perhaps something needs to be uploaded still?

> stack --arch=x86_64 setup
Unable to find installation URLs for OS key: windowsintegersimple64

[snoyberg]

This change appears unnecessary.

[3noch]

Oops... true.

[snoyberg]

Actually, looks verygood. There are two seemingly unnecessary import changes, but that's not a problem. Merging, thanks!

[3noch]

@snoyberg Any idea what's going on with unordered-containers? Is it a bad GHC build? Or perhaps the build plan is concluding that the dependency hash is one thing but the actual build (which is not depending on the same configuration of hashable as normal) produces a different hash?

[snoyberg]

No I'm not sure. I can try to investigate next week, but I don't have much
experience with custom builds like this.

On Fri, Jul 3, 2015, 10:17 AM Elliot Cameron notifications@github.com
wrote:

@snoyberg https://github.com/snoyberg Any idea what's going on with
unordered-containers? Is it a bad GHC build or perhaps the build plan is
concluding that the dependency hash is one thing but the actual build
(which is not depending on the same build of hashable as normal) produces
a different hash?

—
Reply to this email directly or view it on GitHub
#495 (comment)
.

[3noch]

I think there must still be something amiss with the build plan because it works when I hijack the GHC installation. In other words, the following process produces a working build:

1. Delete every conceivable stack cache, both globally and in the repo
2. Remove os: windowsintegersimple constraint (we'll use normal GHC bindist)
3. Run stack --arch=i386 setup and wait for it to download the normal 32-bit GHC 7.10.1 bindist
4. In AppData\Roaming\stack\i386-windows rename ghc-7.10.1 to something else and copy in the custom integer-simple build
5. Run stack --arch=i386 build
6. Voila! It works.

I've also noticed that the windowsintegersimple download ends up in AppData\Roaming\stack\programs instead of AppData\Local\stack like the normal bindist.

[3noch]

Also note that when hijacking the GHC folder, I cannot build my project without specifying custom flags to turn off integer-gmp. It fails with an error that I need integer-gmp.

[3noch]

Perhaps treating integer-simple GHC as a new OS is too heavy handed? It seems that there are numerous places where stack is simply confusing the real OS. Would adding a different configuration setting to select some sort of custom build for a given OS make the job easier?

[snoyberg]

I think you're right, we will need some kind of extra tagging for GHC builds. I think @manny-fp is going to need something like that for adding variants of GHC for Linux based on GMP versions. Perhaps you two could come up with some kind of a plan for what this would look like? I think basically we just want to extend Platform to include an extend field containing some arbitrary text.

[borsboom]

So would we want to use the extended Platform basically wherever Distribution.System.Platform is used now (in the configuration, etc)? Having only glanced at the code, that looks like it would probably work. I could move the libgmp.so.3 detecting code (15ce80c) to where the config is loaded, and that would allow it to be overridden on the command-line.

[snoyberg]

Yes, that's my idea, and make sure that all directories (such as inside
dist) use the tag as well.

On Fri, Jul 3, 2015 at 3:37 PM Emanuel Borsboom notifications@github.com
wrote:

So would we want to use the extended Platform basically wherever
Distribution.System.Platform is used now (in the configuration, etc)?
Having only glanced at the code, that looks like it would probably work. I
could move the libgmp.so.3 detecting code (15ce80c
15ce80c)
to where the config is loaded, and that would allow it to be overridden on
the command-line.

—
Reply to this email directly or view it on GitHub
#495 (comment)
.

[3noch]

That's the direction I was thinking too when I asked the question. Being largely unfamiliar with the code, I can't tell if Platform is primarily targeted at answering "What build of GHC do I use?" or if it is integrated in more complex ways. Of course, which GHC build is used ties into a lot of other things. In other words, I have a hard time peering deeply enough into the code's intent to know where to place the tagging.

[3noch]

It almost seems as if GHC could merely be part of the dependency tree somehow. Of course, it would not fall under the treatment of typical cabal dependencies. I suppose this connection is already present with the resolver deciding which GHC to use. Perhaps we need the custom tagging to exist on the resolver itself.

[3noch]

Shall I open a new issue to add custom build tagging on the resolver?

[snoyberg]

Discussing in a new issue is a good idea