first stab at cabal

[npe9]

This is the first stab at a cabal file for the bluespec compiler. The eventual goal would be to get Bluespec integrated into the various Haskell/OS package managers.

[npe9]

Getting bsc to compile with Cabal and Haskell 2010 required some whitespace fixing. Does Bluespec have a particular indentation/style standard?

[bpfoley]

Getting bsc to compile with Cabal and Haskell 2010 required some whitespace fixing. Does Bluespec have a particular indentation/style standard?

It doesn't yet, but I did a first pass at whitespace cleanup a while ago.

Is there any particular indentation style you think we should adopt? @quark17 any feelings on the subject?

Personally, I don't care too much what the style is, just as long as it's something that's machine-checked and enforced by presubmit hooks and continuous integration checks.

[npe9]

@bpfoley I'm in the same boat as you. I asked some of Sandia's more dedicated Haskellers and I'll if they have any opinions.

[npe9]

@bpfoley @quark17 One of my colleagues suggested using the hlint defaults. One of our projects has an hlint config that we could use as a basis. If you guys are interested I could set that up as a separate pull request.

[quark17]

I would resolve these indentation issues differently. I can make those changes separately, if you'd like? This probably indicates that I have an indentation style in my head that I follow, but I wouldn't know how to communicate it. Most of the BSC code follows one or two styles, and I've tended to stick with whatever the file was already using.

As for the cabal file itself: I apologize that I'm ignorant of how cabal is used to package up programs, not just libraries. (If you can briefly say anything about that or point to packaging of similar tools, that would be helpful.) I definitely think it'd be great if we could package of pieces of the code base as their own libraries, though I don't know if that's independent of this or conflicts with this. Again, I apologize for my ignorance.

I'm concerned that the cabal file contains a list of the 220-ish modules. If we do have to package the whole thing like this, can we do something to make sure that it doesn't get out of sync (if it's not being used in the build) -- something to check it, as part of CI, and maybe something to autogenerate it (or at least the list of modules)?

Finally, I'd prefer if the "author" line reflected that BSC is the result of many authors, not just me. I'm happy to be listed as the maintainer, although at some point that should be a generic email address (like maintainer@b-lang-org). (It's intended that B-Lang-org will become a formal organization to look after BSC and the BSV/BH language.)

[npe9]

Hey @quark17, I'm not partial to any particular indentation style. It would be fine to fix the indentation separately from the cabal file. I'll also be happy to change the author field to anything that you guys would prefer. Just ping me when you guys have a project address.

The main purpose of the cabal file is to integrate bsc and the other Bluespec tools into the rest of the Haskell ecosystem. Cabal files take the place of makefiles and are meant to be spanning trees for every module dependency of the executable. This means they can get very large (e.g. pandoc's is 835 lines). I also believe that stack can use cabal files for dependencies resolution as well.

I don't know of any way to generate a cabal file automatically, it needs to know about the versions of dependencies as well as the local modules. However, I think it should be relatively easy to keep it in sync with a CI hook (I'd be happy to look at integrating cabal into the CI if you guys are interested).

If you're interested in seeing a mature haskell program that's well-integrated into various open-source ecosystems, pandoc (https://github.com/jgm/pandoc) is a very good place to start IMO. I'd be happy to port similar build support to Bluespec.

[quark17]

Thank you again for this. It's been a while, so I wanted to check in.

The whitespace issues have been fixed in main recently (in commits e18a8d3 and 53c4c78). So those are no longer needed.

The author info would still need to be fixed. And I'm wondering how the non-Haskell parts are pulled in -- for example, extra-lib-dirs doesn't look right.

I also don't have a sense of how the cabal project file could replace all the makefiles, since there are non-Haskell libraries that have to be built.

You mentioned that the eventual goal for the cabal file was to get BSC into package managers for OSes. I can understand that, for packaging up BSC, you'd want to be able to build it in a self-contained sandbox, which Cabal supports. However, I believe that you can achieve this without using Cabal to build, as was recently documented in BSC's build instructions (where default can be replaced by a specific directory):

$ cabal v2-install --package-env=default regex-compat syb old-time split
$ make GHC="ghc -package-env default"

I would guess, though, that there other situations where a Cabal project file is needed? Are you thinking of, for example, adding bsc to hackage?

People have suggested replacing the current makefiles with something better, such as cmake. I don't have a sense of whether Cabal can be that alternative; or what would have to change in the BSC repo to allow it to be an alternative. For example, I assume that the Yices and STP libraries would need to be unvendored -- perhaps even replaced by Z3, for which there is a hackage package that could just become a dependency. There's still the Bluesim library (and VPI library) that need to be built, though.