Supporting BNFC

[ivanperez-keera]

I'd like to propose that Cabal support BNFC as a build tool. BNFC is a well-known, multi-language parser generator that supports Haskell via Happy & Alex.

Additional context
From what I understand, the required changes would be:

• Adding bnfc to this list here:

  cabal/Cabal/Distribution/Simple/BuildToolDepends.hs

  Lines 31 to 45 in 0c97920

  	-- The first cases matches first.
  	desugarBuildTool :: PackageDescription
  	-> LegacyExeDependency
  	-> Maybe ExeDependency
  	desugarBuildTool pkg led =
  	if foundLocal
  	then Just $ ExeDependency (packageName pkg) toolName reqVer
  	else Map.lookup name whiteMap
  	where
  	LegacyExeDependency name reqVer = led
  	toolName = mkUnqualComponentName name
  	foundLocal = toolName `elem` map exeName (executables pkg)
  	whitelist = [ "hscolour", "haddock", "happy", "alex", "hsc2hs", "c2hs"
  	, "cpphs", "greencard", "hspec-discover"
  	]

• Adding "fc" to "bnfc" here:

  cabal/cabal-install/Distribution/Client/Init/Heuristics.hs

  Lines 215 to 225 in 72d67bf

  	-- Unfortunately we cannot use the version exported by Distribution.Simple.Program
  	knownSuffixHandlers :: [(String,String)]
  	knownSuffixHandlers =
  	[ ("gc", "greencard")
  	, ("chs", "chs")
  	, ("hsc", "hsc2hs")
  	, ("x", "alex")
  	, ("y", "happy")
  	, ("ly", "happy")
  	, ("cpphs", "cpp")
  	]

• Adding bnfcProgram to this export list:

  cabal/Cabal/Distribution/Simple/Program/Builtin.hs

  Line 13 in 9537238

  module Distribution.Simple.Program.Builtin (

  and this list:

  cabal/Cabal/Distribution/Simple/Program/Builtin.hs

  Lines 69 to 70 in 9537238

  	builtinPrograms :: [Program]
  	builtinPrograms =

  , and introducing a bnfcProgram definition in that module. For bnfc, it appears that just --version is enough to detect the version number.

Questions:

• Would such a patch be accepted?
• If so, would those changes be enough?
• How to handle the need to arguments to bnfc (e.g., --haskell -p <PATH> -o <directory> <file.cf>? Would doing this immediately make cabal understand --with-bnfc, --with-bnfc-options and bnfc-options:?

[phadej]

• I'm ok about adding bnfc to known suffix preprocessors, but
• I think we have strong assumption that packagename and exename is the same, which isn't: bnfc and BNFC which might require some bigger changes.
• desugarBuildTool is for legacy build-tools, and I think shouldn't be changed
• I suspect things need changes if there is no one-to-one mapping between source MyLanguage.fc and generated MyLanguage.hs. I guess bnfc generates some .x and .y (and .hs) files. I suspect the multiple output file would case architectural problems.

Adding bnfc-options: to .cabal file syntax is a big deal, so everything else have to be figured out until we can commit to that change, we'll need to live with if forever. Note, we don't have alex-options nor happy-options as these tools self-configure from the input file. I'd appreciate that kind of working mode.

[ivanperez-keera]

I suspect things need changes if there is no one-to-one mapping between source MyLanguage.cf and generated MyLanguage.hs. I guess bnfc generates some .x and .y (and .hs) files. I suspect the multiple output file would case architectural problems.

This assumption is correct. From one .cf file, BNFC generates:

• A .x alex file
• A .y happy file.
• Several .hs files (containing e.g., the AST).

Adding bnfc-options: to .cabal file syntax is a big deal, so everything else have to be figured out until we can commit to that change, we'll need to live with if forever.

Makes sense not to add it then.

I think we have strong assumption that packagename and exename is the same [...] which might require some bigger changes.
[...] I suspect the multiple output file would case architectural problems.

I certainly would not expect all of these changes to happen in Cabal just for this. Is this versatility (i.e., more than one file being generated, having different package and executable names) generally desired for the future of cabal, or would this just be annoying to maintain and not provide much benefit? I see their benefit in theory, but I'm just not sure if you've every encountered this before, or expect to.

[phadej]

• having different package and executable names

I don't think this is big issue, it's just not done. built-tool-depends already requires to specify BNFC:bnfc (optional version range) format. But the knownSuffixHandlers is [(String, String)], where it should be [(PackageName, UnqualComponentName, Extension)]. I think it will be a good change anyway (less stringy types, even Extension is String in filepath).

• more than one file being generated

Is the tricky bit build-system wise. Cabal have to know what files are generated. I suspect one-to-one processing is very deep in how Cabal is made. There are e.g. issues with ordering of c2hs flle processing which Cabal doesn't known anything about (see #6233 for more).

[andreasabel]

* more than one file being generated

Is the tricky bit build-system wise. Cabal have to know what files are generated. I suspect one-to-one processing is very deep in how Cabal is made. There are e.g. issues with ordering of c2hs flle processing which Cabal doesn't known anything about (see #6233 for more).

Found this comment on situations where several files are generated:
#3545 (comment)

[ivanperez-keera]

Just a comment which I don't know if/how it is related.

Currently, with cabal-3.4, adding BNFC to the setup build dependencies does not seem to be enough (or I don't know how to do it):

custom-setup                                                                    
  setup-depends:                                                                
      base    >= 4.11.0.0                                                       
    , Cabal   >= 2.0                                                            
    , process                                                                   
    , BNFC    >= 2.9.1   

Instead of installing BNFC as an executable, therefore letting me run it, it installs BNFC as a library. The result is that the following setup program:

-- | Custom Setup that runs bnfc to generate the language sub-libraries         
-- for the parsers included in Ogma.                                            
module Main (main) where                                                        
                                                                                
import Distribution.Simple         ( defaultMainWithHooks, hookedPrograms,      
                                     postConf, preBuild, simpleUserHooks )      
import Distribution.Simple.Program ( Program (..), findProgramVersion,          
                                     simpleProgram )                            
import System.Process              ( system )                                   
                                                                                
-- | Run BNFC on the grammar before the actual build step.                      
--                                                                              
-- All options for bnfc are hard-coded here. There is an open bug in Cabal's    
-- github repo about supporting BNFC.                                           
main :: IO ()                                                                   
main = defaultMainWithHooks $ simpleUserHooks                                   
  { hookedPrograms = [ bnfcProgram ]                                            
  , postConf       = \args flags packageDesc localBuildInfo -> do               
      _ <- system "bnfc --haskell -p Language.W -o src/ grammar/W.cf"           
      postConf simpleUserHooks args flags packageDesc localBuildInfo            
  }                                                                             
                                                                                
-- | TODO: This should be in Cabal.Distribution.Simple.Program.Builtin.         
bnfcProgram :: Program                                                          
bnfcProgram = (simpleProgram "bnfc")                                            
  { programFindVersion = findProgramVersion "--version" id                      
  }

cannot find bnfc in the PATH:

Warning: 'hs-source-dirs: src' directory does not exist.
/bin/sh: 1: bnfc: not found
Preprocessing library for xyz-language-w-0.0.1..
setup: can't find source for Language/W/AbsW in src, dist/build/autogen,
dist/build/global-autogen

although the directory src does exist in the repo. Btw, if I first install BNFC first with:

cabal install bnfc

then it puts the executable in $HOME/.cabal/bin and my package compiles and installs correctly.

[gbaz]

Correct, as discussed in the ticket you linked, build-tool-depends is the correct thing to specify.

[ivanperez-keera]

Indeed. Unfortunately, that did not work for me on 3.6 because of #7644.