OS and toolchain support matrix not defined

[bpfoley]

From personal communications, I heard that bluespec.com used to do their compiler builds in a Debian 3.1 VM with GHC 6.12 so that the resulting glibc and shared library dependencies were old enough that a bunch of older versions of OSes such as RedHat Enterprise Linux would be able to run them.

Going forward, I think should explicitly say what OSes and compiler versions we want to support are.

Related to this, we should possibly consider other ways of providing backwards compatibility without tying ourselves to old libraries and toolchains, such as by using statically linked libraries for bsc/bluesim.

[quark17]

Bluespec had been building a "least-common denominator" release (not with GHC6 for years though) but gave that up and has been building separate releases for each of the supported OSes. Specifically, for various Debian and RHEL versions (which work respectively on Ubuntu and CentOS). The last release in 2019 was for Debian 8 and 9 and RHEL 7. Those were built using the GHC version installed on the OS. I think GHC 8.0 was the latest version being used in a release (we hadn't yet attempted a Debian10 release which is 8.4), though I'd run the source through 8.2, 8.4, and 8.8 compilers and added the if-defs needed to get it to compile.

[thoughtpolice]

In practice, for GHC, "Latest contemporary RHEL" + "Latest contemporary Debian" basically defined the lower bound for compilation support. Choosing one may be best. Many people substitute Debian with Ubuntu in this case. I think that's a good starting point, and soon enough Ubuntu 20.04 will be out.

More specifically, GHC 8.4 still sees a good amount of support since 8.10 hasn't come out yet, so I think that's an excellent starting point for compiler support, provided you're willing to go that far, and it means we should be able to use modern tooling and library versions without much hassle.

[bpfoley]

Just for my reference. GHC doesn't actually ship directly with RedHat Enterprise Linux 7, but it's part of the "EPEL" (Extra Packages for Enterprise Linux) repository. The version shipped there is GHC 7.6.3, so that's probably as old as we need to support.

http://mirror.arizona.edu/fedora-epel/7/x86_64/Packages/g/
https://www.haskell.org/downloads/linux#epel-for-rhelcentosetc

The good news is that means we get to use anything in the base libraries up to base-4.6
https://wiki.haskell.org/Base_package

Debian 8 is Jessie, and also packages GHC 7.6.3 https://packages.debian.org/jessie/ghc
Debian 9 is Stretch, which jumps to GHC 8.0.1 https://packages.debian.org/stretch/ghc
Debian 10 is Buster and moves up to GHC 8.4.4 https://packages.debian.org/buster/ghc

[bpfoley]

(I'll also note that if you're using Stack to provide your Haskell toolchain, the oldest working resolver they currently support is ghc-7.10.3 (and the newest right now is ghc-8.8.2)

ghc-7.8.4 exists too, but the version of cabal that comes with doesn't work properly.

[neelgala]

On centos7, the default ghc version (7.6.3) doesn't build with the latest master. I had to upgrade to 8.0.2 to build successfully.

Steps:

   yum install -y yum-plugin-copr
   yum copr enable petersen/ghc-8.0.2
   yum install -y ghc tk tk-devel tcl-devel tcl flex bison tcl-dev autoconf  \
      gperf git cabal-install gcc-c++ make cabal-install
   cabal update
   cabal install regex-compat syb old-time split
   git clone https:/B-Lang-org/bsc.git --recursive
   cd bsc/
   make all
   make install

A note on centos installation would be good in the README.