Should flag Example default to True?

[andreasabel]

ansi-terminal/ansi-terminal/ansi-terminal.cabal

Lines 28 to 30 in 2a4a6d8

	Flag Example
	Description: Build the example application
	Default: False

I am getting:

$ cabal run ansi-terminal-example
...
Error: cabal: Cannot run the executable 'ansi-terminal-example' because it is
marked as 'buildable: False' within the 'ansi-terminal.cabal' file (at least
for the current configuration). If you believe it should be buildable then
check the .cabal file to see if the buildable property is conditional on
flags. ...

So I have to type cabal run -f+example ansi-terminal-example.

Would there be any drawback to default flag example to True?
Wouldn't users that have build-depends: ansi-terminal still only get the library as before?

[mpilgrem]

I think the drawback of the flag defaulting to true is that the example executable would be built when it is not wanted, including when ansi-terminal is specified as a dependency. Most people building the package have no need for the executable binary, which acts both as a test of the library and a tutorial (although in the latter case, the source code is more useful than the binary).

[andreasabel]

example executable would be built when it is not wanted, including when ansi-terminal is specified as a dependency.

Is that so? My experiment suggests otherwise.
Package BNFC has a library and an executable. If I build-depends on it, only the library is built.
E.g. this depend-on-bnfc project:

cabal-version: 3.0
name: depend-on-bnfc
version: 0

executable depend-on-bnfc
  main-is: DependOnBNFC.hs
  build-depends:
    , base
    , BNFC

Building it does this:

$ cabal build
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - alex-3.2.7.2 (exe:alex) (requires build)
 - string-qq-0.0.4 (lib) (requires build)
 - BNFC-2.9.4.1 (lib) (requires build)
 - depend-on-bnfc-0 (exe:depend-on-bnfc) (first run)

So it does no build BNFC (exe:bnfc), just the library.

For reproducibility, here also DependOnBNFC.hs:

import BNFC.CF

main :: IO ()
main = putStrLn "Executed DependOnBNFC"

Since you are the stack maintainer, maybe you were thinking in terms of stack build. So, I extended my experiment to stack with:

echo "resolver: lts-19.33" > stack.yaml
stack build

Indeed, stack also builds the executable:

...
Building executable 'bnfc' for BNFC-2.9.4..
...
BNFC          > Installing library in .../BNFC-2.9.4-...
BNFC          > Installing executable bnfc in /Users/abel/.stack/snapshots/x86_64-osx/49df129ff59db6386b73253188faa0d52d9b6b3cef1403a4dddbb8782f3c0978/9.0.2/bin

Isn't this an error on the side of stack?
If I want the executable, I need to specify build-tool-depends: BNFC:bnfc.
build-depends: BNFC should really only build the library.

[mpilgrem]

I did have in mind Stack. Its online help explains "With dependencies, Stack will always build the library (if present) and all executables (if any), and ignore test suites and benchmarks." and my experimentation suggested that was accurate.

Whether or not that is a 'bug' in Stack, I'll have to investigate further. Stack aims to support Cabal 1.18.1.5 and I am conscious that build-tool-depends was first introduced with Cabal 2.0. It may be a backwards-compatability thing.

EDIT: This comment commercialhaskell/stack#4132 (comment) suggests that it is a deliberate design decision on the part of Stack, justified in part by backwards compatability.

[andreasabel]

Ok, maybe then this is blocked upstream. Once stack changes its build strategy and fully embraces build-tool-depends, it can be revisited.

[mpilgrem]

Cabal-2.0.0.2 first shipped with GHC 8.2.1. LTS 10.0 provided GHC 8.2.2 on 2017-12-19, replacing LTS 9.21 (GHC 8.0.2). That means that Stack will fully embrace build-tool-depends from 2024-12-19, given its 'seven years' approach to backwards compatability.

[sol]

This is not a bug in stack. cabal-install used to behave the same way until somebody decided to introduce a breaking change. While the new behavior is not bad per se, it broke a lot of code. At that time stack decided to not follow that breaking change.

@mpilgrem of course, you can reevaluate at some point, just be aware that this will affect a lot of people, especially in-house projects that use hspec-discover.

Personal opinion: Breaking other peoples code for minor gains is never a nice thing to do.

I think at this point, it's no secret anymore that this "let's randomly break stuff" mentality is one of the contributing factors to Haskell's decline.

[andreasabel]

I agree that one should err on the conservative side rather than on the progressive.

However, it is also desirable that the Cabal language has just one semantics, not two different ones.
It so happened that build-tool-depends was split off build-depends because the latter was not precise enough (ambiguity between depending on the library or the executable). Removing this ambiguity is per se a good thing.

Is there a problem with build-tool-depends: hspec-discover?