Explicitly support building with -fno-code #1176

Open
nh2 opened this Issue Jan 11, 2013 · 11 comments

Projects

None yet

6 participants

@nh2
nh2 commented Jan 11, 2013 edited

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
Haskell member

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

@nh2

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).

@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.

@crockeea crockeea referenced this issue in SublimeHaskell/SublimeHaskell Nov 13, 2014
Closed

cabal build succeeds but SublimeHaskell build fails #158

@AndrewBrinker

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

@ttuegel ttuegel added the library label Apr 23, 2015
@ttuegel ttuegel added this to the Cabal-1.24 milestone Apr 23, 2015
@23Skidoo 23Skidoo modified the milestone: Cabal 1.24, Cabal 1.26 Feb 21, 2016
@ezyang ezyang modified the milestone: Cabal 2.0 Sep 6, 2016
@ezyang ezyang changed the title from Cabal error when building with -fno-code to Explicitly support building with -fno-code Sep 8, 2016
@ezyang ezyang self-assigned this Sep 8, 2016
@ezyang ezyang added this to the 2.0 milestone Sep 8, 2016
@ezyang ezyang modified the milestone: , 2.0 Sep 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment