Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
simonjantsch opened this issue Dec 25, 2015 · 5 comments
Assignees
Milestone

Comments

@simonjantsch
Copy link

@simonjantsch simonjantsch commented Dec 25, 2015

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
Copy link
Contributor

@quyse quyse commented Dec 26, 2015

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
Copy link
Author

@simonjantsch simonjantsch commented Dec 27, 2015

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 borsboom self-assigned this Dec 30, 2015
borsboom added a commit that referenced this issue Dec 30, 2015
@borsboom
Copy link
Contributor

@borsboom borsboom commented Dec 30, 2015

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
Copy link
Contributor

@quyse quyse commented Dec 31, 2015

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

@simonjantsch
Copy link
Author

@simonjantsch simonjantsch commented Dec 31, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.