.. _default.build:

default.build
=============

.. rst-class:: lead

**.dvt/default.build** is an argument file that configures DVT's internal builder. By default, whenever a full build is performed, DVT starts by reading this file. It may contain:

-  comments
-  directives in two forms:

   - +directive+arg1[+arg2+...]
   - -directive arg1[ arg2 ...]
-  top files. Anything that is not a directive or comment is regarded as path to a **top file**.

.. note:: 
   
   Unknown directives are ignored. In general, DVT-specific directives start with **+dvt_**. Unknown directives that start with this prefix are flagged with a warning.

The internal builder parses each top file, following includes/imports as specified by the language. Some directives (**parsing directives**) allow you to control how files are compiled based on their extension, for example using System Verilog 1800-2012 for \*.sv, Verilog 2001 for \*.v, VHDL 1076-2008 for \*.vhdl and e Language 1647-2011 parser for \*.e. The parsing directives are either generic or mode specific.

.. note::
   
   A project is built by analyzing source code with one or more of DVT's parsers depending on the :ref:`Project Natures`. 
   
   Even if build configuration files in the **.dvt** folder specify certain files to be compiled with a specific language syntax, they will not be analyzed unless the corresponding nature is enabled for the project. The language syntax to project nature mapping is:

   .. list-table::
      :header-rows: 0
      :widths: 50 50

      * - e Language
        - e Nature    
      * - Verilog, SystemVerilog
        - vlog Nature
      * - VHDL
        - vhdl Nature
      * - C/C++
        - c/cpp Nature
      * - UPF/CPF
        - upf/cpf Nature
      * - PSS
        - pss Nature
      * - SLN
        - sln Nature
      * - SDL
        - sdl Nature
  
   DVT for VS Code has currently support only for Verilog / SystemVerilog and VHDL.

In general, the directives are similar with the arguments (or flags) that you would pass to any compiler/simulator.

A build file may include other argument files and so on. The internal builder follows the included files as it encounters them (as if part of a continuous stream). Note that the way a file is included (for example with ``-f`` or ``-F``) has an influence on how paths inside the included files are interpreted. For more details see :ref:`Including Other Argument Files`.

To simplify the flow integration, DVT supports several :ref:`Compatibility Modes`. This capability allows you to reuse existing arguments or argument files that you already use for a particular simulator invocation.
