<commit_before>========================
Task Inputs/Dependencies
========================

Tasks with dependencies are now introduced in the
:doc:`getting started guide </Getting-Started/More-About-Settings>`,
which you may wish to read first. This older page may have some additional detail.

*Wiki Maintenance Note:* This page should have its overlap with the
getting started guide cleaned up, and just have any advanced or
additional notes. It should maybe also be consolidated with :doc:`Tasks`.

An important aspect of the task system introduced in sbt 0.10 is to
combine two common, related steps in a build:

1. Ensure some other task is performed.
2. Use some result from that task.

Previous versions of sbt configured these steps separately using

1. Dependency declarations
2. Some form of shared state

To see why it is advantageous to combine them, compare the situation to
that of deferring initialization of a variable in Scala. This Scala code
is a bad way to expose a value whose initialization is deferred:

::

     // Define a variable that will be initialized at some point
     // We don't want to do it right away, because it might be expensive
    var foo: Foo = _

     // Define a function to initialize the variable
    def makeFoo(): Unit = ... initialize foo ...

Typical usage would be:

::
<commit_msg>Docs: present the TaskInputs page as motivation and for deeper understanding<commit_after>==========================
Tasks/Settings: Motivation
==========================

This page motivates the task and settings system.
You should already know how to use tasks and settings, which are
described in the :doc:`getting started guide </Getting-Started/More-About-Settings>`
and on the :doc:`Tasks` page.

An important aspect of the task system is to combine two common, related steps in a build:

1. Ensure some other task is performed.
2. Use some result from that task.

Earlier versions of sbt configured these steps separately using

1. Dependency declarations
2. Some form of shared state

To see why it is advantageous to combine them, compare the situation to
that of deferring initialization of a variable in Scala. This Scala code
is a bad way to expose a value whose initialization is deferred:

::

     // Define a variable that will be initialized at some point
     // We don't want to do it right away, because it might be expensive
    var foo: Foo = _

     // Define a function to initialize the variable
    def makeFoo(): Unit = ... initialize foo ...

Typical usage would be:

::

{'fraction_non_alphanumeric': 0.08886255924170616, 'fraction_numerical': 0.004344391785150079, 'mean_word_length': 3.9089147286821704, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3618843', 'n_tokens_mistral': 635, 'n_tokens_neox': 596, 'n_words': 367}