| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
! => not; && => and, || => or
|
|
Most built-in rules are just described by their name, assuming they
are known to the user anyway. One exception, however, are "export"
targets, as those serve as interfaces to (logical) repositories and
hence is supposed to have a documentation of the target itself. Over
time, however, "configure" targets have evolved to become internal
interfaces (maybe even for an external target), e.g., to provide
default values and hence make better use of the actual export target.
Therefore it is desirable to provide a bit more information when
asked to describe a "configure" target.
- As "configure" targets have a fixed set of keys, adding a "doc"
field is a conservative extension; this can be useful to give an
overview what the target is about.
- An important information of a "configure" target is the target
that is configured. While this, in general, is an expression, in
the typical cases, the description is very short (a literal target
name, or a variable). So we can afford to show the definition.
|
|
...instead of not_null const ptr.
|
|
|
|
...to properly fallback to local api if needed.
|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
...to track changes during refactoring easier.
|
|
...to track changes during refactoring easier.
|
|
Once a RepositoryConfig instance gets populated, it must never be
changed again. Therefore, all functions accepting these instances
should only take them as pointers to const.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
Also cleans up the logging when parsing the serve service
configuration file.
|
|
|
|
|
|
|
|
With the introduction of 'just serve', export targets can now be
built also independently from one another based on their
corresponding minimal repository configuration, as stored in the
target cache key.
In this context, this commit changes the RepositoryConfig usage
from one global (static) instance to pointers passed as necessary
throughout the code.
|
|
... in the human-readable description. More precisely, for
any implicit target field, show
- the field documentation given (if any), and
- the resolved targets this field contains.
However, do not show the actual name of the field, as this name
is internal to the rule and not part of the interface.
|
|
|
|
... with the order for "field_doc" being taken from
"string_fields", "target_fields", and "config_fields"
(in that order). For "config_doc", the order is taken
from the "config_vars" list. Thus, being consistent with
the (non-JSON) pretty printing of rules.
|
|
Signed-off-by: Goetz Brasche <goetz.brasche@huawei.com>
|
|
|
