Cabal: Explicitly support building with -fno-code

[nh2]

Summary by @ezyang. There is no way to ask Setup to just typecheck a package. It sort of works if you pass -fno-code via --ghc-options but that's purely accidental.

---

I use cabal build --ghc-options="-Wall -fno-code" to quickly get all errors/warnings from a project and show them in an editor.

However, when I have something like this

executable Shared.so
  hs-source-dirs:
    apps
  main-is:
    Shared.hs
  build-depends:
      base >= 4 && <= 5
  ghc-options:
    -optl-shared -optc-DMODULE=Shared -no-hs-main -fPIC -shared -dynamic
  cc-options: -DMODULE=Shared -shared
  ld-options: -shared /home/niklas/opt/haskell-7.4/lib/ghc-7.4.2/libHSrts-ghc7.4.2.so

in my cabal file that only builds a shared object, I get:

Warning: the following files would be used as linker inputs, but linking is not being done: dist/build/...
ghc: no input files
Usage: For basic information, try the `--help' option.

Should we get this warning although we explicitly said -fno-code?

If yes, can we add an option to disable this kind of warning so that it does not clutter the warnings I am actually interested in (to show in the editor)?

---

Update:

(The original title was _Add option to disable non-linking warnings with -fno-code_.)

I just realized that there is an actual bug in this:

After the warning, due to the ghc _error_ cabal will just stop and build no further. This should not happen as there is no code to build!

[nh2]

This even happens when you don't have a configuration as above, but a way more normal one, like hspec's cabal file.

A normal build looks like this:

Building hspec-1.4.3...                                                                     
Preprocessing library hspec-1.4.3...
[ 1 of 14] Compiling Test.Hspec.Compat ( src/Test/Hspec/Compat.hs, dist/build/Test/Hspec/Compat.o )
...
[14 of 14] Compiling Test.Hspec.QuickCheck ( src/Test/Hspec/QuickCheck.hs, dist/build/Test/Hspec/QuickCheck.o )
In-place registering hspec-1.4.3...
Preprocessing executable 'hspec-discover' for hspec-1.4.3...
[1 of 2] Compiling Run              ( hspec-discover/src/Run.hs, dist/build/hspec-discover/hspec-discover-tmp/Run.o )
[2 of 2] Compiling Main             ( hspec-discover/src/Main.hs, dist/build/hspec-discover/hspec-discover-tmp/Main.o )
Linking dist/build/hspec-discover/hspec-discover ...

But cabal build --ghc-options="-fno-code" gives:

Building hspec-1.4.3...                                                
Preprocessing library hspec-1.4.3...
[ 1 of 14] Compiling Test.Hspec.Compat ( src/Test/Hspec/Compat.hs, nothing )
...
[14 of 14] Compiling Test.Hspec.QuickCheck ( src/Test/Hspec/QuickCheck.hs, nothing )
/usr/bin/ar: dist/build/Test/Hspec.o: No such file or directory

Note this only breaks if the code hasn't been built yet (e.g. after cabal clean). If it has been built before, cabal build --ghc-options="-fforce-recomp -fno-code" correctly yields:

Building hspec-1.4.3...
Preprocessing library hspec-1.4.3...
[ 1 of 14] Compiling Test.Hspec.Compat ( src/Test/Hspec/Compat.hs, nothing )
...
[14 of 14] Compiling Test.Hspec.QuickCheck ( src/Test/Hspec/QuickCheck.hs, nothing )
In-place registering hspec-1.4.3...
Preprocessing executable 'hspec-discover' for hspec-1.4.3...
[1 of 2] Compiling Run              ( hspec-discover/src/Run.hs, nothing )
[2 of 2] Compiling Main             ( hspec-discover/src/Main.hs, nothing )

I think this is a bug - cabal build --ghc-options="-fno-code" should always work, no matter if code had been generated before!

[nh2]

@23Skidoo Can you reproduce this with some of your packages (or hspec as above)?

[23Skidoo]

@nh2 I'm a bit swamped right now, will look at this later.

[nh2]

I was thinking into this direction (https://github.com/nh2/cabal/commit/0c51929cf6c3a7fd1850daf4124b3c28da1175db) but then realized that what I want is not that easy: You could perform a "read-only" typecheck with cabal to build the library, but as soon as you want to typecheck an executable (that depends on your own library and is in a different directory to avoid repeated compilation), you actually need the result of the library compilation.

Actually, you only need the *.hi files; it should be possible to generate them without further code generation, but I don't know how (see http://stackoverflow.com/questions/14306934/haskell-how-to-only-generate-hi-file-with-ghc).

[nh2]

In the mean time, an easy work around would be #1177 - making a full cabal build instant by skipping linking if not necessary. (This could also be accomplished with -c, but that still performs unnecessary registering and unnecessarily links .so files.) On success (otherwise we have an error anyway), we can immediately run cabal build --ghc-options="-fforce-recomp -Wall -fno-code" which will work now since all necesssary files already exist.

However, this doesn't work as described in my original bug report: ghc reports ghc: no input files and terminates before the remaining warnings can be generated.

[nh2]

https://github.com/nh2/cabal/compare/no-code-link-shared is a proposal to skip linking on -fno-code. It fixes the error described.

An explicit cabal option to disable this step might be better, though.

[ezyang]

I just added an option -fwrite-interface, to dump interface files precisely when you want to do something like typecheck a library, and then typecheck a dependent executable.

[nh2]

@ezyang Can you explain a bit more how this is intended to be used?

[ezyang]

If you are planning on doing only typechecking cycles, and you have a library + executable Cabal file, run -fno-code and -fwrite-interface to typecheck the library, and then you will be able to type check the executable (because the library hi files are available.) Needs some UI polish, obviously!

[asivitz]

I also see this error when building even static libraries or executables. Would be happy to hack on it if that's helpful, although I haven't looked at cabal's code before. Not sure if this is a beginner-level problem or not.

[alilleybrinker]

This issue seems to persist, and is currently causing minor frustration in using SublimeHaskell, whose default build mechanism uses two builds: first a standard cabal build and then cabal build -v0 --ghc-options="-fforce-recomp -Wall -fno-code" to gather warnings. This issue is causing SublimeHaskell to display a bothersome error pane every time a project is recompiled (which happens every save). It's a minor issue, but a fix would be appreciated.

Here is the relevant SublimeHaskell issue: https://github.com/SublimeHaskell/SublimeHaskell/issues/158

[nh2]

A tip from @rwbarton just now on #ghc, we could use -e which is like ghci, but terminates.

TH works in ghci (due to use of bytecode), so this should be almost as fast as -fno-code (it still generates the bytecode which is _some_ code, but in my experience that's much faster than even -O0).

[mightybyte]

I'd like to add another vote for this ticket. I'm not sure what the UI should be (cabal typecheck or cabal build --typecheck come to mind). Whether it's called "typecheck", "no-code", "fast", etc is not a huge issue (although "no-code" never seemed very intuitive to me personally). The important thing in my mind is to have this as an explicit cabal option somewhere so the fastest compile loop is more discoverable.

[sboosali]

the -e option doesn't work for me, because I'm using cabal build as a replacement for ghci in a project where the interpreter can't load at all because of linking errors (i.e. and thus cabal repl, ghcid, dante, etc can't help).

[ice1000]

I'd like to add another vote for this ticket. I'm not sure what the UI should be (cabal typecheck or cabal build --typecheck come to mind). Whether it's called "typecheck", "no-code", "fast", etc is not a huge issue (although "no-code" never seemed very intuitive to me personally). The important thing in my mind is to have this as an explicit cabal option somewhere so the fastest compile loop is more discoverable.

I like this idea! Any update for this?

[sboosali]

same. having a subcommand is better for discovery too.

e.g. someone who tab-completes cabal t for testing will notice
typecheck and they start using it.

also, even if though it's (currently) equivalent to just a few options,
it's one less thing a user needs to do, and they can trust that it's the
right way to do it.

On Mon, Nov 5, 2018, 01:01 Tesla Ice Zhang <[email protected] wrote:

I'd like to add another vote for this ticket. I'm not sure what the UI
should be (cabal typecheck or cabal build --typecheck come to mind).
Whether it's called "typecheck", "no-code", "fast", etc is not a huge issue
(although "no-code" never seemed very intuitive to me personally). The
important thing in my mind is to have this as an explicit cabal option
somewhere so the fastest compile loop is more discoverable.

I like this idea! Any update for this?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/haskell/cabal/issues/1176#issuecomment-435800938, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACNoMYL71RKmKlWpNLuh9UZ7nimie7JSks5ur_6BgaJpZM4AW0uK
.

[23Skidoo]

+1 for adding a subcommand (cabal typecheck) from me.