| Age | Commit message (Collapse) | Author |
|---|
|
... and ensure that pandoc processes them correctly. In particular,
add an empty line around itemize environments.
|
|
|
|
|
|
|
|
- For the rule functions TREE_OVERLAY and DISJOINT_TREE_OVERLAY
call the argument "$1", to align with the argument name for
BLOB and TREE.
- For the built-in functions `"tree_overlay"` and `"disjoint_tree_overlay"`,
align this the built-in function `"tree"` and allow staging of
the resulting tree.
|
|
|
|
... and remove it from the future design, as it is already implemented.
|
|
Clarify the handling and extent of proposed debug-related
configuration fields in the CC defaults.
|
|
|
|
|
|
... as it turns out that the synchronous writing is fast enough and
hence we can avoid all the problems of background processes.
|
|
Also update the README.
|
|
...instead of using the master branch.
|
|
Reduce interference of invocation logging with regular logging
operations; in particular, restrict just-mr passing the --async-profile
option only to build commands and thus avoiding race conditions with
calls to `analyse` that rely on having a graph available immediate
after invocation.
|
|
|
|
- specify that what is cloned is the workspace root of the target
repository
- disambiguate what is referred to as the 'start' and 'target'
repository
|
|
|
|
Marking a source repository 'as plain' means that the whole source
repository tree will get imported as a repository type
corresponding to the source type. In this case, additional pragmas
than those supported by the inndividual imports might need to be
set.
Solve this by supporting the just-mr-style 'pragma' field also in
the source description, for all sources also accepting the
'as plain' field. Currently support only the 'special' pragma.
Document change and add test for plain imports that checks this
feature.
|
|
In particular, any transitive 'file'-type repository will inherit
any given '{to_git: true}' pragma in the import description
objects. Note that this technically can only happen for transitive
'file' repositories imported from a 'file' source, so in all other
cases such a pragma would not have any effect.
Document change and extend the import from 'file' source test to
check this feature.
|
|
Add the artifacts and outputs of the updated rules, as well as
some explanatory remarks.
|
|
- As we build a binary hello, make it an extension of the hello
we had before.
- Make the passing of time more explicit.
- Add actual output of rerunning the tutorial.
|
|
As our defaults rule supports flags common for C and C++ use
them, especially as our example only uses common flags.
|
|
|
|
|
|
... in particular in the case of targets producing precisely one
artifact; this better emphasizes the idea that we talk to the tool
in terms of targets. While there, also add some clarifying comments.
|
|
|
|
|
|
|
|
The "generic" rules deliberately resolves conflicts on identical
paths in a latest-wins fashion (seeing all artifacts as later than
all runfiles) to allow an easy way to define actions. However, the
inputs stage obtained by this resolution can still contain conflicts
and those are an error. Properly detect those. Also clarify in the
documentation, that only conflicts on identical paths are resolved
in the described priority, not semantic overlap.
|
|
... rather than as future design. While there, also add target-level
caching as a service to the list of documentation pages.
|
|
The 'type' field is optional and informs both the way to unpack
the archive and which type imported file repositories should be
rewritten as in the output configuration. Mirrors the 'just-mr'
types, with options for tarballs and zip-like archives, defaulting
to tarballs if missing.
The 'mirrors' field is treated the same as for 'git' sources.
The 'subdir' field is optional and accounts for the fact that the
actual root of the source repository might be a subpath in the
unpacked archive, as opposed to Git repositories where it is
reasonable to expect that the sources root is the top-level
directory.
|
|
...to refer to repositories as a chain of bindings to be followed
starting from one of the known repositories (existing or imported).
Both the initial and the target repositories are to be kept during
deduplication.
|
|
|
|
|
|
|
|
... specifically for the use case of target files depending on the
directory structure.
|
|
|
|
|
|
|
|
|
|
This is an essential step in the debugging process that was missing
in the tutorial.
|
|
Originally, the expression lanuage only contained a function to
deduplicate a list, keeping only the right-most occurence. The
reason was that this is the order needed for linking: a library
providing an open symbol has to come on the command line after the
library using that symbol (and hence making it an open symbol).
However, by now use cases have emerged that require a topological
sorting where definition comes before use; also, when composing
the value of PATH from fragments, we usually want to keep the first
occurrence in order for it to take precedence. Therefore, also
add "nub_left" as built-in function, allowing a more condense (and
slightly more efficient) description in rules instead of the
revserse-nub_right-reverse pattern.
|
|
... allowing to select only the keys in a specific subdir,
and move the them to top-level.
|
|
... and drop the corresponding design document as implemented.
|
|
|
|
|
|
directory
... instead of always having to execute actions in the top-level directory.
|
|
|
|
|
|
|
