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.
Related
This question poses problems that are distinct from those discussed here: How do you read debug VCS version info from a Go 1.18 binary?
I am having trouble getting go build -buildvcs=true to insert correct version information when building executables out of a git repo that has the following structure:
go version go1.18.4 linux/amd64
in project:
go.mod
cmd/exe1/main.go
cmd/exe2/main.go
pkg/pkg1/...
pkg/pkg2/...
(1) If I cd project;go build -buildvcs=true -o /tmp/exe1 cmd/exe1/main.go then the BuildInfo included in the exe includes Deps entries for all the dependencies of all the packages, but there is no embedded Setting with key vcs.revision, and the Dep entry for the module named in go.mod is (devel). I guess this latter issue is related to how to specify versions for modules, which I have not yet looked into, and therefore I assume it's using a default value.
(2) If I cd project/cmd/exe1;go build -buildvcs=true -o /tmp/exe1 (leaving out any relative path specifying what to build) then the BuildInfo included in the exe does NOT include Deps entries but DOES include the vcs.revision
Questions:
Is there any way to get both Deps and vcs.revision into BuildInfo?
Is this directory structure ok? The documentation for this stuff is not in "reference" format, and many important details are spread out throughout all of the tutorials and howtos. Quite frustrating to get to the bottom of these behaviors.
It seems to me go should embed a vcs.revision whenever generating an executable, but before I open a bug, I wanted to get community feedback on whether this is expected behavior when specifying a relative target on the command line. I've seen that that can be an issue in general, with go build.
Any pointers to the right place to read a comprehensive guide about this would be great.
I recently started using Go. I installed go's extension on vscode and I can use some commands like go run and go build but when I run go test I get the following error:
go: cannot find main module; see 'go help modules'
although I have a *_test.go file.
When I run go help modules, I get the following output:
Modules are how Go manages dependencies.
A module is a collection of packages that are released, versioned, and
distributed together. Modules may be downloaded directly from version control
repositories or from module proxy servers.
For a series of tutorials on modules, see
https://golang.org/doc/tutorial/create-module.
For a detailed reference on modules, see https://golang.org/ref/mod.
By default, the go command may download modules from https://proxy.golang.org.
It may authenticate modules using the checksum database at
https://sum.golang.org. Both services are operated by the Go team at Google.
The privacy policies for these services are available at
https://proxy.golang.org/privacy and https://sum.golang.org/privacy,
respectively.
The go command's download behavior may be configured using GOPROXY, GOSUMDB,
GOPRIVATE, and other environment variables. See 'go help environment'
and https://golang.org/ref/mod#private-module-privacy for more information.
You have to initialize the project before you can run test:
go mod init puppy
https://golang.org/cmd/go#hdr-Module_maintenance
I have two stack projects, A and B. B depends on A; B's stack.yaml is the following:
resolver: lts-12.10
packages:
- .
- ../path/to/A/
where there exists a file ../path/to/A/stack.yaml, and stack build in A's directory builds successfully.
In B's directory, I stack build --ghc-options -v, and stack builds A, then proceeds to trying to build B, failing to find A's modules. I don't know how stack works, but the verbose output shows that GHC is looking only in ./.stack-work and ./src/ - not in A's directory. Running stack dot produces a diagram with nodes A and B, but no arrows between them. It's like stack is seeing A but not as a dependency of B.
stack solver reports that no changes need to be made.
Using latest stack (v1.7.1)
Found the answer on another SO article: the piece I was missing was adding A's package name to the dependencies list in B's package.yaml file. This hadn't occured to be earlier, as I'd incorrectly assumed that dependencies was for upstream repository packages only.
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!
I forked ELKI from https://github.com/elki-project because I want to keep up to date with the latest development status while making my own changes and additions to the source (which I will possibly provide via pull request if it's sensible).
I followed the instructions in the README.md to package it with mvn package but there was no .jar created in elki/target/ - when checking out the release0.7.1 branch, it worked and I could start the minigui with java -cp elki-0.7.1.jar de.lmu.ifi.dbs.elki.application.ELKILauncher.
Is there a recommended way to try out the latest changes on the master?
We are currently in the process of modularizing ELKI.
But mvn package does create .jar files in elki/target/ here:
elki/target/elki-0.7.2-SNAPSHOT.jar
elki/target/elki-0.7.2-SNAPSHOT-javadoc.jar
elki/target/elki-0.7.2-SNAPSHOT-sources.jar
elki/target/dependency/elki-core-dbids-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-core-dbids-int-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-core-util-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-docutil-0.7.2-SNAPSHOT.jar
elki/target/dependency/elki-logging-0.7.2-SNAPSHOT.jar
elki/target/dependency/hamcrest-core-1.3.jar
elki/target/dependency/javaparser-core-2.3.0.jar
elki/target/dependency/junit-4.12.jar
elki/target/dependency/trove4j-3.0.3.jar
The main jar, ./elki/target/elki-0.7.2-SNAPSHOT.jar is runnable, but will only include the command line interface because of modularization - the minigui is optional now.
If you want a all-in-one bundle (as distributed on the web site), you need to enable the Maven profile bundle in addition to the functionality you want to include (e.g. mvn -Psvg,svm,uncertain,bundle package).