cabal init should allow exe and/or lib and/or tests

[alanz]

A common pattern (and the default for stack) is to have an app directory with the Main.hs for an executable, a library section and a test one.

Also, using the same directory for an exe and a lib can lead to compilation of the lib both as a lib and for the exe.

Proposal

1. In the exe only case, put it in an app directory.
2. Do not make it exclusive. Ask for exe, lib, test.

Perhaps even ask for benchmarks. Default no, initially.

[m-renaud]

This use case is now supported in the most recent version of cabal via the following cabal init options:

• --exe - Generate an executable
• --lib - Generate a library
• --libandexe - Generate both a library and executable
• --application-dir - Directory for the package's executable
• --source-dir - Directory for the packages' library sources
• --tests - Flag to turn on test suite generation
• --test-dir - Where the tests should be placed.

There is no support currently for generating benchmarks, we should open another issue for that if desired.

[andreasabel]

@m-renaud : I suggest a reorganization of these flags according to #7251 (comment)

cabal init --source-dir=. does not do anything meaningful unless I also pass --lib. Shouldn't the following be implications?

Flag	Implied flag
--source-dir	--lib
--application-dir	--exe
--test-dir	--tests

Also, shouldn't --lib --exe be the same as --libandexe (and the latter be redundant)?

[m-renaud]

Hey @andreasabel, thanks for flagging this! I'm not opposed to the above recommendation, but I think we should also consider an alternative: warn (or exit init entirely) if an "unused" flag is passed. For example:

cabal init --source-dir src
WARNING: --source-dir flag has no effect unless used alongside --lib or --libandexe

shouldn't --lib --exe be the same as --libandexe (and the latter be redundant)?

1. Yup, I definitely agree that --lib --exe should be equivalent to --libandexe. If it's not, I'll 100% review a PR to make it so (or may get to it myself eventually)!
2. Removing a flag would be a "breaking" change in workflows, and would require updating a bunch of docs (both owned by cabal, easy; as well as external tutorials, very hard), so I'd lean against removing it as a historical artifact. Ideal, no, but I'd rather have a redundant flag than someone new to Haskell and cabal be following a tutorial that they found via search engine that uses --libandexe and it not work for them.

[andreasabel]

@m-renaud:

we should also consider an alternative: warn (or exit init entirely) if an "unused" flag is passed.

Yes, unused flags should surely trigger a warning or error.

Since cabal init is essentially a wizard, helping the user with the initial configuration of a project, I would prioritize user-friendliness, tough. In particular, enable DRY expression (don't repeat yourself) and the most sensible defaults.

I agree with you of course that historic flags (--libandexe) shouldn't be deleted, but continue to work as long as possible. At the same time, they should alert the user that they are obsolete.