Cabal support for bnfc

[gdetrez]

Add support in cabal to build bnf files using bnfc (like what is done with alex and happy). This would, among other things, make bnfc own compilation easier.

[peti]

I've done that for the cabal2nix utility at https://github.com/NixOS/cabal2nix/tree/ebnf-parser-for-nix. Check out the Setup.hs file.

[andreasabel]

Yes, one could modify Setup.lhs to include code that generates the LBNF parser from the BNF.cf file, using BNFC. Currently Setup is the default script:

bnfc/source/Setup.lhs

Lines 1 to 6 in fb85ff1

	#!/usr/bin/env runghc
	> module Main where
	> import Distribution.Simple
	> main :: IO ()
	> main = defaultMain

However, I don't see the point really. It seems better to have the BNFC-generated LBNF parser committed to the repo and included in the sdist tarball to avoid boot-strapping issues.

[peti]

However, I don't see the point really. It seems better to have the BNFC-generated LBNF parser committed to the repo and included in the sdist tarball to avoid boot-strapping issues.

The point is that Cabal will do that for you automatically, i.e. it will generate the source code and include it in the generater sdist tarball. Checking generating source code into the git repository, however, is a really bad idea because people will forget to update those files. This will happen a couple of times, and then you'll decide that you'll need some automatism to ensure the generated files up-to-date. That automatism is Cabal.

[andreasabel]

@peti, I agree that it would be nicer if Cabal would know about the BNFC-generated files.

I did some research but did not find out how to teach Cabal about BNFC. Cabal seems to have a set of hardwired build-tools it knows about, like happy, alex etc., but there is no plugin mechanism I know of that would allow me to integrate BNFC. I would have to add it to the Cabal sources, it seems. Am I right?

@fgaz : Maybe you have some information about the build-tool handling in Cabal?

(Besides the technical difficulties, there is a bit of concern about backwards compatibility of BNFC. Later versions of BNFC might change the interface the generated files expose, so that code relying on a certain interface would not work with file generated by a newer BNFC. Of course, if one is worried about that, one can always commit the BNFC generated files to the source tree and not invoke BNFC in the build process.)

[fgaz]

@andreasabel

I would have to add it to the Cabal sources, it seems. Am I right?

Yes. Either that, or a custom setup has to be used

The relevant module is Cabal.Distribution.Simple.PreProcess. There are some comments on how it works in there.

Later versions of BNFC might change the interface the generated files expose, so that code relying on a certain interface would not work with file generated by a newer BNFC

If correct version bounds are used on build-tool-depends (and if bnfc follows the PVP), this is not a concern.

[fgaz]

@peti

Checking generating source code into the git repository, however, is a
really bad idea because people will forget to update those files. This
will happen a couple of times, and then you'll decide that you'll need
some automatism to ensure the generated files up-to-date. That
automatism is Cabal.

Or CI :)
One could set up CI so that it checks that preprocessor(source) == generated

Another nice way of treating generated files, IMO, is to only include them in release tarballs. This way:

• The repo remains clean
• The tarballs (the only source users should need to build) do not need preprocessing
• There is no way for the generated files to get out of sync, if they are generated together with the tarball

It's not necessarily bad to wrap cabal, or to have some preprocessing steps for development/distribution, especially if this avoids a custom Setup. Cabal itself does this (though for BC reasons).

[andreasabel]

So a first step could be to have the Haskell backend of BNFC generate a Setup.hs script that does the correct invocation of BNFC. Once the logic has been found out, one could look at integrating BNFC as native build-tool into Cabal. Not sure what their policy is, though, if they would accept new hard-wired build tools.

@fgaz: Since I have you here, do you know how the hardwiring of e.g. happy works? Happy has several options, but in the cabal file I have no place to declare the options for invoking happy, do I? The build-tools field only accepts version bounds on happy and the like, no options for the invocation.

P.S.: There is PR #173 to create a cabal file. Maybe this can be extended to also create the Setup file.

[fgaz]

As far as I know there's no way to pass options to preprocessors. One way of working around that could be to accept options in the .cf file itself, like GHC language pragmas.

[fgaz]

Once the logic has been found out, one could look at integrating BNFC as native build-tool into Cabal. Not sure what their policy is, though, if they would accept new hard-wired build tools.

I just had a chat in #hackage on freenode and no, they would not. On the other hand, they're open to the possibility of adding extensible preprocessing in Cabal

[andreasabel]

See also this discussion on adding BNFC support to cabal: haskell/cabal#6726

[andreasabel]

@peti wrote:

Checking generating source code into the git repository, however, is a really bad idea because people will forget to update those files.

If you use a front-end to version control like magit which puts changed files in your face, you won't easily forget to update. However, it is still a bad idea, since it can be a nuisance if you have merge conflicts in these generated files. Version control should really have the concept of a generated file with its dependencies, then it would know that such files are not precious and simply move in sync with the files they are generated from...