Update NEWS file

1 files changed, 269 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index 0f47384..e16e5c7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,272 @@
+Version 0.13.0
+
+  * Support for project-specific configuration.
+
+    A project can now use the new config directive to define config.*
+    variables similar to the build system core and modules. For example:
+
+    config [bool]   config.libhello.fancy    ?= false
+    config [string] config.libhello.greeting ?= 'Hello'
+
+    These variables can then be used in buildfiles and/or propagated to the
+    source code using the command line, .in file substitution, etc. For
+    example:
+
+    if $config.libhello.fancy
+      cxx.poptions += -DLIBHELLO_FANCY
+
+    cxx.poptions += "-DLIBHELLO_GREETING=\"$config.libhello.greeting\""
+
+    See the "Project Configuration" chapter in the manual for details.
+
+  * Support for ad hoc recipes.
+
+    With ad hoc recipes we can now provide custom implementation of operations
+    (update, test, etc) for certain targets. For example:
+
+    hxx{config}: hxx{config-linux}:   include = ($cxx.target.class == 'linux')
+    hxx{config}: hxx{config-windows}: include = ($cxx.target.class == 'windows')
+    hxx{config}: hxx{config-macos}:   include = ($cxx.target.class == 'macos')
+    hxx{config}:
+    {{
+      cp $path($<) $path($>)
+    }}
+
+    Another, more elaborate example:
+
+    import! xxd = xxd%exe{xxd}
+
+    <{hxx cxx}{foo}>: file{foo.bin} $xxd
+    {{
+      diag xxd ($<[0])
+
+      i = $path($<[0]) # Input.
+      h = $path($>[0]) # Output header.
+      s = $path($>[1]) # Output source.
+      n = $name($<[0]) # Array name.
+
+      # Get the position of the last byte (in hex).
+      #
+      $xxd -s -1 -l 1 $i | sed -n -e 's/^([0-9]+):.*$/\1/p' - | set pos
+
+      # Write header and source.
+      #
+      echo "#pragma once"                         >$h
+      echo "extern const char $n[0x$pos + 1];"   >>$h
+      echo "extern const char $n[0x$pos + 1]= {"  >$s
+      $xxd -i <$i                                >>$s
+      echo '};'                                  >>$s
+    }}
+
+    Note that in both examples, the utilities (cp, echo, and sed) are builtins
+    which means these recipes are portable. See the Testscript manual for the
+    list of available builtins.
+
+    Ad hoc recipes can also be used to customize a part of the build chain
+    handled by rules. For example, in embedded systems development it is often
+    required to perform a custom link step:
+
+    obje{foo}: cxx{foo}
+    obje{bar}: cxx{bar}
+    exe{ld}: obje{ld ld1}
+    {{
+      diag ld $>
+      $cxx.path $cc.loptions $cxx.loptions $cxx.mode -o $path($>) $path($<) \
+        $cxx.libs $cc.libs
+    }}
+
+    While the above recipes are for the update operation, ad hoc recipes can
+    be used for other operations, such as test. For example:
+
+    exe{hello}: cxx{hello}
+    % test
+    {{
+      diag test $>
+      $> 'World' >>>?'Hello, World!'
+    }}
+
+    The above recipes are written in a shell-like language called Buildscript
+    that has similar semantics to Testscript tests. Another language that can
+    be used to write recipes is C++. For example:
+
+    ./:
+    {{ c++ 1
+
+      recipe
+      apply (action, target& t) const override
+      {
+        text (recipe_loc) << "Hello, " << t;
+        return noop_recipe;
+      }
+    }}
+
+    In this release support for ad hoc recipe is at the "technology preview"
+    stage. In particular, there is no documentation and are known rough edges,
+    especially around diagnostics.
+
+  * Support for project-local importation.
+
+    An import without a project name is now treated as importation from the
+    same project. For example, given the libhello project that exports the
+    lib{hello} target, a buildfile for an executable in the same project
+    instead of doing something like this:
+
+    include ../libhello/
+    exe{hello}: ../libhello/lib{hello}
+
+    Can now do this:
+
+    import lib = lib{hello}
+    exe{hello}: $lib
+
+    Note that the target in project-local importation must still be exported
+    in the project's export stub. In other words, project-local importation
+    goes through the same mechanism as normal import.
+
+  * Support for ad hoc importation and "glue buildfiles".
+
+    If the target being imported has no project name and is either absolute or
+    is a relative directory, then this is treated as ad hoc importation.
+    Semantically it is similar to a normal import but with the location of the
+    project being imported hard-coded into the buildfile.
+
+    This type of import can be used to create a special "glue buildfile" that
+    "pulls" together several projects, usually for convenience of development.
+    One typical case that calls for such a glue buildfile is a multi-package
+    project. To be able to invoke the build system driver directly in the
+    project root, we can add a glue buildfile that imports and builds all the
+    packages:
+
+    import pkgs = */
+    ./: $pkgs
+
+    See the "Target Importation" section in the manual for details.
+
+  * Support for value subscripts.
+
+    A value subscript is only recognized in evaluation contexts (due to
+    ambiguity with wildcard patterns; consider: $x[123].txt) and should be
+    unseparated from the previous token. For example:
+
+    x = ($y[1])
+    x = (($f ? $y : $z)[1])
+    x = ($identity($y)[$z])
+
+  * New legal{} target type and config.install.legal variable.
+
+    This allows separation of legal files (LICENSE, AUTHORS, etc) from other
+    documentation. For example:
+
+    ./: ... doc{README} legal{LICENSE}
+
+    $ b install ... config.install.legal=/usr/share/licenses/hello/
+
+  * Support for <var>-substitutions in config.install.* values.
+
+    The currently recognized variable names are <project> and <private> which
+    are substituted with the project name and private subdirectory,
+    respectively. This can be used along these lines:
+
+    $ b config.install.libexec='exec_root/lib/<project>/' install
+
+    The private installation subdirectory can be used to hide the
+    implementation details of a project. This is primarily useful when
+    installing an executable that depends on a bunch of libraries into a
+    shared location, such as /usr/local/. For example:
+
+    $ b config.install.private=foo install
+
+    See the "Install Module" chapter in the manual for details.
+
+  * The $process.run*() functions now recognize a number of portable builtins.
+    Refer to the Testscript manual for the list and details.
+
+  * New $defined(<variable>) and $visibility(<variable>) functions.
+
+  * New $target.process_path() function analogous to $target.path().
+
+  * New $bin.link_member() function.
+
+    Given a linker output target type ("exe", "lib[as]", or "libu[eas]") this
+    function returns the target type of lib{} group member ("liba" or "libs")
+    that will be picked when linking a lib{} group to this target type.
+
+  * New scripting builtins: date, env.
+
+  * New variable block applicability semantics in dependency chains.
+
+    Before the block used to apply to the set of prerequisites before the last
+    colon. This turned out to be counterintuitive and not very useful since
+    prerequisite-specific variables are less common than target-specific.
+
+    The new rule is if the chain ends with the colon, then the block applies
+    to the last set of prerequisites. Otherwise, it applies to the last set of
+    targets. For example:
+
+    ./: exe{test}: cxx{main}
+    {
+      test = true        # Applies to the exe{test} target.
+    }
+
+    ./: exe{test}: libue{test}:
+    {
+      bin.whole = false  # Applies to the libue{test} prerequisite.
+    }
+
+  * Test and install modules are now implicitly loaded for simple projects.
+
+    While these can be useful on their own, this also makes the test and
+    install operations available in simple projects, which is handy for "glue"
+    projects that "pull" (using ad hoc import) a bunch of other projects.
+
+  * The translated {c,cxx}.std options are now folded into the compiler mode
+    options. This makes them accessible from ad hoc recipes.
+
+  * Common pkg-config .pc file in addition to static/shared-specific.
+
+    The common .pc file is produced by ignoring any static/shared-specific
+    poptions and splitting loptions/libs into Libs/Libs.private.
+
+    It is "best effort", in a sense that it's not guaranteed to be sufficient
+    in all cases, but it will probably cover the majority of cases, even on
+    Windows, thanks to automatic dllimport'ing of functions.
+
+  * The ~host configuration now only contains the cc and bin modules
+    configuration.
+
+    Also added the ~build2 configuration that contains everything (except
+    config.dist.*) to be used for build system modules.
+
+  * Reworked tool importation support.
+
+    Specifically, now config.<tool> (like config.cli) is handled by the import
+    machinery (it is like a shorter alias for config.import.<tool>.<tool>.exe
+    that we already had).
+
+    This also adds support for uniform tool metadata extraction that is
+    handled by the import machinery. As a result, a tool that follows the
+    "build2 way" can be imported with metadata by the buildfile and/or
+    corresponding module without any tool-specific code or brittleness
+    associated with parsing --version or similar outputs. See the cli
+    tool/module for details.
+
+    Finally, two new flavors of the import directive are now supported:
+    import! triggers immediate importation skipping any rule-specific logic
+    while import? is optional import (analogous to using?). Note that optional
+    import is always immediate. There is also the import-specific metadata
+    attribute which can be specified for these two import flavors in order to
+    trigger metadata importation. For example:
+
+    import? [metadata] cli = cli%exe{cli}
+
+    if ($cli != [null])
+      info "cli version $($cli:cli.version)"
+
+  * Reserved backtick (`) and bit-or (|) in evaluation context for future use.
+
+    Specifically, they are reserved for future support of arithmetic
+    evaluation contexts and evaluation pipelines, respectively.
+
 Version 0.12.0
 
   * Support for dynamically-buildable/loadable build system modules.