Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Cabal error when building with -fno-code #1176

Open
nh2 opened this Issue · 11 comments

5 participants

Niklas Hambüchen Mikhail Glushenkov Edward Z. Yang Axis Sivitz Andrew Brinker
Niklas Hambüchen

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!

Niklas Hambüchen

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!

Niklas Hambüchen

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

Mikhail Glushenkov
Collaborator

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

Niklas Hambüchen

I was thinking into this direction (nh2@0c51929) 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).

Niklas Hambüchen

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.

Niklas Hambüchen

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.

Edward Z. Yang
Collaborator

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.

Niklas Hambüchen

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

Edward Z. Yang
Collaborator

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!

Axis Sivitz

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.

crockeea crockeea referenced this issue in SublimeHaskell/SublimeHaskell
Closed

cabal build succeeds but SublimeHaskell build fails #158

Andrew Brinker

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: SublimeHaskell/SublimeHaskell#158

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.