Where does stack haddock (or stack build --haddock) place the documentation that it generates?
That depends on where the package that the haddocks are generated for "belongs". Haddocks for "local" packages, that are part of a stack project, will be placed inside the .stack-work directory inside the project directory. Haddocks for snapshot packages will be placed in the stack root directory, typically ~/.stack.
The easiest way to discover the exact path is stack haddock --open. For example, run stack haddock --open base or stack haddock --open my-pkg in a project that contains a package with that name.
The command (non-trivial, does not default to the current package) returns the location which the user then has to copy-paste into an open browser. Not much simpler than navigating to the (deeply hidden address)!
Suggestion: could the stack community add a link in .stack-work to the index.html files produced? Easy to find and can be opened with a double-click!
Related
Stack is suddenly misbehaving. I created a new project, wrote some code, needed a new dependency (containers, to get Data.Map.Strict), so I edited my project .cabal file to add the dependency and now stack is rewriting my .cabal file to throw away my edits (which makes the build fail).
What stupid simple thing have I missed?
(I committed what I had to git and started over.)
rm -fr Problem032
stack new Problem032
cd Problem032
stack setup
stack build
stack exec Problem032-exe
all works fine. But then...
vi Problem032.cabal
to add ",containers" to the lib build-depends
cd src
git checkout -- Lib.hs
to get my old broken code back
cd ..
stack build
Results in my .cabal file getting rewritten (to lose the new dependency) and then the build fails.
This is because the default stack template now uses hpack for package descriptions. You can either delete package.yaml or instead edit it. Stack 1.6.1 which was just released, has much better behavior for this circumstance.
It's my understanding (1) that the build-depends section in my project's .cabal file will ensure packages specified there are present in the resolver specified in stack.yml are available (in the appropriate versions) and used when I test or run my package (e.g., with stack ghci or stack test, etc.).
I also gather (2) that the extra-deps section of my stack.yml is used to acquire packages that are not in the specified resolver.
But I'm confused about the role of
stack build some-package
How does this differ from extra-deps? Will some-package be used when I stack test or stack ghci etc.? Why use it instead of just adding some-package to extra-deps? (And, have I got (1) and (2) right?)
The main purpose of the build command is to actually trigger the build, i.e. compilation. By default stack build will build all the "local" packages listed in the stack.yaml's packages section. If you pass a package name as an argument to build, that has usually one of the following two purposes:
You want to build only a certain (local) package in a multi-package project
Or you you want to install an executable from a non-local package, for example hlint. Typically you will do this with stack install PKG which is a shortcut for stack build --copy-bins PKG.
One core design principle of stack is that builds should be reproducible, i.e. a project with the same code and same configuration should always give the same result for stack build.
That means that stack build or stack install will never change the project configuration or add dependencies to the project.
For more details on the build command, take a look at the relevant docs.
I installed goclipse in my eclipse, and setup the preferences as follows :
Preferences->Go->Tools
ProjectExplorer
Now when I create a new GoFile (HelloWorld.src), the file is saved in D:/GO/TestProject/src. But when I build the same file, the bin and pkg folders are empty and hence when I run the file the following error comes :
resource does not have a corresponding go package
Unable to run the code because of this error.
Your project path should be D:\GO\src\TestProject in order to match the workspace expected as described in https://golang.org/doc/code.html
Then, your GOPATH should point to D:\GO (NOT ...\src)
The go tool will automatically use $GOPATH/src, $GOPATH/bin or $GOPATH/pkg when appropiate for each case.
And as icza pointed out, your program should have a package main statement on the top of your go file to be recognized as an executable, unless you want to create a package, in that case, you should name your package as you want.
I'm starting to experiment with Go and I'm facing an issue that (I think) doesn't exist in languages that use a virtual machine.
I have a src/test/main.go file that references my templates inside src/test/views/ folder.
When I use go run main.go it runs but when do go install and then inside my bin folder run the executable (./test) I get an error:
views/edit.html: no such file or directory
So, how does Go compiles my project (file/folder structure related) and how to use paths in a way that allows me to use either go run and go install/executable?
If you specify a relative path in your code, as in views/edit.html it will also be looked up relative to the binary location. You need to either make the path absolute, or use some logic to determine where your templates will be located.
Another option would be to use https://github.com/jteeuwen/go-bindata or https://github.com/elazarl/go-bindata-assetfs that will save you the hassle.
I'm trying to build a pre-existing HaxePunk project in sublime (switching away from FlashDevelop).
problem: Error: Could not process argument
Here's my .hxml file:
-neko
-cp "c:/path/to/project/src"
-main Main
I've read somewhere that you shouldn't use the /src convention for your src files. That's annoying, since I want assets and binaries in their own directories separate from src files. How do I properly configure this?
You really should use the the src convention and not stuff everything within the same directory. You also don't want to make the build specific to your machine, so in you example above you don't want an absolute path but a relative one. So try the following:
#content of c:/path/to/project/build.hxml
-neko bin/output.n
-cp src
-main Main
Note that for -cp you use the relative path. The path is relative to where haxe is executed. That usually coincides with where your build.hxml file is, but it is not mandatory.
Also, you didn't specify an output file for neko. Note that you will have to create the directory bin by hand because the compiler will not do that for you and will complain if it doesn't exist.
These information are general and in no way tied with Sublime. Sublime should play just nice with these settings.