Different behaviour when using "stack build "pkg"" and "stack build" to implicitly build the pkg

[simonjantsch]

I'm trying to build an existing project, that has dependencies which are provided by github links, with stack and I encountered following:

When build the project with stack build the dependency seems to build fine, I get following in the in the end of the buildlog:

In-place registering bindings-llvm-0.1...
Installing library in
/home/simon/Uni/BachArbeit/vvt/.stack-work/install/x86_64-linux/lts-2.22/7.8.4/lib/x86_64-linux-ghc-7.8.4/bindings-llvm-0.1
Registering bindings-llvm-0.1...

When however running stack build bindings-llvm I get following error:

Could not resolve file /home/simon/Uni/BachArbeit/vvt/.stack-work/downloaded/d3f241eec39c8de03ed09f9a4c4c0fe4b40e69f77a840d113d98d87cd8e21092/In file included from wrapper/HaskellPass.h

and the package does not build. I get the same, when cloning the repo of the dependency from github and try to build it with
stack. Shouldn't stack build $pkg and implicitly building the package with stack build yield the same results?

Any help is appreciated! Thanks in advance,

--Simon

[quyse]

Seeing this too right now with my own package which builds C++ files as well as Haskell.

flaw-bullet-0.1.0.0: configure
Configuring flaw-bullet-0.1.0.0...
flaw-bullet-0.1.0.0: build
Preprocessing library flaw-bullet-0.1.0.0...

Could not resolve file /home/quyse/workspace/flaw/flaw-bullet/In file included from src/bullet/src/LinearMath/btQuaternion.h

I tried to build the package with cabal, and it turns out that there's a compile error in C++, and gcc prints out a message mentioning paths to some C++ header files (actually In file included from src/bullet/src/LinearMath/btQuaternion.h is a beginning of gcc's message). I guess stack tries to resolve gcc's output lines as paths (as it prepended this line with package's root directory), rather than just print them untouched, hence instead of list of C++ compile errors I see this useless message.

$ stack --version
Version 1.0.0, Git revision 3bc26237b5b3c387b8fd564459ea4dd88fd58b30 (2939 commits) x86_64

[simonjantsch]

Ah interesting, I looked at the log when building with cabal and I get this message at the same place where the error comes when using 'stack build bindings-llvm'

*** C Compiler:
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-x' 'c++' 'wrapper/HaskellPass.cpp' '-o' '/tmp/ghc3287_0/ghc3287_0.s' '-S' '-O' '-D__GLASGOW_HASKELL__=706' '-DTABLES_NEXT_TO_CODE' '-I/usr/lib/llvm-3.5/include' '-DNDEBUG' '-D_GNU_SOURCE' '-D__STDC_CONSTANT_MACROS' '-D__STDC_FORMAT_MACROS' '-D__STDC_LIMIT_MACROS' '-g' '-O2' '-fomit-frame-pointer' '-std=c++11' '-fvisibility-inlines-hidden' '-fno-exceptions' '-fPIC' '-Woverloaded-virtual' '-ffunction-sections' '-fdata-sections' '-Wcast-qual' '-DHS_LLVM_VERSION=305' '-O2' '-I' 'dist/build' '-I' '/usr/lib/llvm-3.5/include' '-I' 'wrapper' '-I' '.' '-I' '/usr/lib/ghc/unix-2.6.0.1/include' '-I' '/usr/lib/ghc/time-1.4.0.1/include' '-I' '/usr/lib/ghc/bytestring-0.10.0.2/include' '-I' '/usr/lib/ghc/base-4.6.0.1/include' '-I' '/usr/lib/ghc/include'

In file included from wrapper/HaskellPass.h:4:0:
0,
from wrapper/HaskellPass.cpp:1:

/usr/lib/ghc/include/HsFFI.h:29:0:
warning: "__STDC_LIMIT_MACROS" redefined
#define __STDC_LIMIT_MACROS
^

I see this warning in the log when implicitly building the package, by calling 'stack build' in the parent directory. So it seems that stack handles warnings differently when building the package implicitly as dependency or directly. Also warnings should be ignored by default, no? And the log message is not really helpful.

[borsboom]

I've committed a change that should fix this. Please try it and close the issue if so.

The problem was that the exception handling for resolving paths in warning messages was incorrect, and it would crash if it encountered a bad path instead of just passing it through unchanged. For warnings, this didn't effect multi-package builds because the build log is only shown if there is an error, so it would never try to resolve the paths in the warnings (whereas single-package builds do always show the warnings).

[quyse]

@borsboom With latest version of stack the issue is gone for me. Cool!

[simonjantsch]

It works for me too, thank you! I'm closing the issue