Configuration File(s)

[ScottFreeCode]

This came up in an old issue I was looking at, concerning Cabal integration. (By the way, Stack integration may or may not work automatically if Cabal integration is added. I believe Stack relies on Cabal for a lot under the hood but has a different list of default tools because they want to handle ones packages with GHC differently from how Cabal does?)

It would be nice to have the options that are currently all set on the commandline instead be settable in some kind of configuration file. This would avoid having to write different BNFC options into build scripts or call a shell script just containing the BNFC call with its options. (Options could still be overridden on the commandline to support experimentation or one-time actions like Makefile generation.) Besides, if you ask me I'd say CLI options are imperative and configuration is declarative!

Ideally, since there might be multiple language implementation backends (not generally useful but possibly so if, say, it's a library and the language is used/embedded in some other languages), multiple BNFC configuration files could be supported and chosen-between somehow. (To be honest though, I don't have enough of a concrete use case for this to tell you if any specific solution will be a good fit. How would the languages/config-file be chosen: CLI flag, environment variable? May depend on the build setup…)

[andreasabel]

I think CLI programs would benefit from a standard that allows to pass configuration in from different sources:

1. Global configuration file.
2. Local default configuration file.
3. Command line options. There could be a --config-file option that loads in another config file.

In general, a configuration item given later overwrites an earlier item.
For cumulative options, later items add to earlier items.
There should be a way to reset cumulative options to null.

BNFC does not have any cumulative options; but --config-file could be treated as a cumulative option.

Usually --name=value is generally also used for cumulative options, but --name+=value would be a more natural syntax.

Ideally, there would be an integrated Haskell package for CLI configuration, that handles both configuration files and command line option parsing. There is a list here: https://wiki.haskell.org/Command_line_option_parsers, but dating from 2017; not sure it includes what I want.

[ScottFreeCode]

I'm always surprised that isn't universally a thing, myself. Seems like what you described is both logical and is what all the most mature programs trend towards, but so often they've just reimplemented it individually.

Probably the one other thing that could be helpful is environment variables, though in BNFC's case that's less likely to be useful; they're easier to hide/encrypt in e.g. cloud deploys than commandline options or files, so good for passing secrets that need to be passed again if the app should need to be rebooted.

If I can find a spare minute I'll look over that list; if nothing fits the bill maybe I can add "fork one of these that looks like a good starting point and make it a complete configuration system" to my to-do list.