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.

Sign up for GitHub

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

Jump to bottom

Remove v2-prefix from Quickstart guide (backport #9087) #9124

Merged
merged 1 commit into from
Jul 14, 2023
Merged

Remove v2-prefix from Quickstart guide (backport #9087) #9124

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 19 additions & 19 deletions doc/nix-local-build.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,19 +11,19 @@ local builds with this command (configuring is not necessary):

::

$ cabal v2-build
$ cabal build

To open a GHCi shell with this package, use this command:

::

$ cabal v2-repl
$ cabal repl

To run an executable defined in this package, use this command:

::

$ cabal v2-run <executable name> [executable args]
$ cabal run <executable name> [executable args]

Developing multiple packages
----------------------------
Expand Down Expand Up @@ -51,37 +51,37 @@ directory, run the command: (using cabal-install-2.0 or greater.)

::

$ cabal v2-build all
$ cabal build all

To build a specific package, you can either run ``v2-build`` from the
To build a specific package, you can either run ``build`` from the
directory of the package in question:

::

$ cd cabal-install
$ cabal v2-build
$ cabal build

or you can pass the name of the package as an argument to
``cabal v2-build`` (this works in any subdirectory of the project):
``cabal build`` (this works in any subdirectory of the project):

::

$ cabal v2-build cabal-install
$ cabal build cabal-install

You can also specify a specific component of the package to build. For
example, to build a test suite named ``package-tests``, use the command:

::

$ cabal v2-build package-tests
$ cabal build package-tests

Targets can be qualified with package names. So to request
``package-tests`` *from* the ``Cabal`` package, use
``Cabal-tests:package-tests``.

Unlike sandboxes, there is no need to setup a sandbox or ``add-source``
projects; just check in ``cabal.project`` to your repository and
``v2-build`` will just work.
``build`` will just work.

Cookbook
========
Expand All @@ -94,14 +94,14 @@ line::

profiling: True

Now, ``cabal v2-build`` will automatically build all libraries and
Now, ``cabal build`` will automatically build all libraries and
executables with profiling. You can fine-tune the profiling settings
for each package using :cfg-field:`profiling-detail`::

package p
profiling-detail: toplevel-functions

Alternately, you can call ``cabal v2-build --enable-profiling`` to
Alternately, you can call ``cabal build --enable-profiling`` to
temporarily build with profiling.

How can I have a reproducible set of versions for my dependencies?
Expand Down Expand Up @@ -173,13 +173,13 @@ built version.
The global package store is ``~/.cabal/store`` (configurable via
global `store-dir` option); if you need to clear your store for
whatever reason (e.g., to reclaim disk space or because the global
store is corrupted), deleting this directory is safe (``v2-build``
store is corrupted), deleting this directory is safe (``build``
will just rebuild everything it needs on its next invocation).

This split motivates some of the UI choices for Nix-style local build
commands. For example, flags passed to ``cabal v2-build`` are only
commands. For example, flags passed to ``cabal build`` are only
applied to *local* packages, so that adding a flag to
``cabal v2-build`` doesn't necessitate a rebuild of *every* transitive
``cabal build`` doesn't necessitate a rebuild of *every* transitive
dependency in the global package store.

In cabal-install 2.0 and above, Nix-style local builds also take advantage of a
Expand All @@ -194,10 +194,10 @@ are not currently built on a per-component basis.
Where are my build products?
----------------------------

A major deficiency in the current implementation of v2-build is that
A major deficiency in the current implementation of ``cabal build`` is that
there is no programmatic way to access the location of build products.
The location of the build products is intended to be an internal
implementation detail of v2-build, but we also understand that many
implementation detail of ``cabal build``, but we also understand that many
unimplemented features can only be reasonably worked around by
accessing build products directly.

Expand Down Expand Up @@ -245,7 +245,7 @@ the time it takes to execute a rebuild cycle. While the details of how
``cabal-install`` does caching are an implementation detail and may
change in the future, knowing what gets cached is helpful for
understanding the performance characteristics of invocations to
``v2-build``. The cached intermediate results are stored in
``build``. The cached intermediate results are stored in
``dist-newstyle/cache``; this folder can be safely deleted to clear the
cache.

Expand All @@ -261,7 +261,7 @@ this folder (the most important two are first):
already available in the store.)
``source-hashes`` (binary)
The hashes of all local source files. When all local source files of
a local package are unchanged, ``cabal v2-build`` will skip
a local package are unchanged, ``cabal build`` will skip
invoking ``setup build`` entirely (saving us from a possibly
expensive call to ``ghc --make``). The full list of source files
participating in compilation is determined using
Expand Down
Loading