| Age | Commit message (Collapse) | Author |
|---|
|
Also link it in the README.
|
|
|
|
via a 'SYMLINK' constructor function. This works similarly to the
'FILE' construct, but the name given must point to a non-upwards
symlink and a symlink artifact is being generated from it.
Also updates the relevant tests.
|
|
|
|
... as the result of evaluating "timeout scaling" or "execution
properties". This implicit default is already implemented and
allow simple access to variables without having to care for default
values, thus having simpler rules.
|
|
|
|
... so that users who want use just as an execution service for
other build tools are aware and don't run into errors due to
incompatible hashes.
|
|
|
|
|
|
|
|
|
|
... also for CC tests, as this contains the shared tools, e.g.,
for flakyness handling.
|
|
I know "boost rap" is a popular music genre among C++ programmers today,
but nevertheless this is a typo.
|
|
|
|
|
|
Co-authored-by: Sascha Roloff <sascha.roloff@huawei.com>
|
|
|
|
|
|
|
|
... while following symbolic links. In this way, bootstrapping
is possible against preinstalled dependencies that symbolic links
or special files in their directories.
|
|
... describing the background as well as proposing a possible
way to treat symbolic links in our build system.
|
|
|
|
|
|
|
|
... by using the fully declared rules-cc repository and
feeding ed from stdin.
|
|
... by explicitly specifying the protobuf repository and
using just-import-git to import the rules-cc repository.
Furthermore, protobuf's subdir "examples" is used directly
and all targets are created in the top-level module.
|
|
... by adding some remarks and creating all tests in module
"tests".
|
|
|
|
|
|
|
|
... given that binaries now only have "private-proto" (as there
are no public dependencies of a binary anyway). While there, also
hint on the script for git imports, to simplify the setup of
the example.
|
|
... on parts a first-time reader might (and actually did) stumble upon.
|
|
Compared to the previous commit, the action graphs for just
and its unit tests are unchanged.
- Git hash of action graph for ["",""]:
c6e75f17abd7ffaab6ff9bb725ad67ec0bf6c973
- Git hash of action graph for ["test/buildtool","TESTS"]:
8063dfb3dd7daa9ae01d95c177e14946f785c57e
Refactor:
- "local cflags" to "private-cflags"
- "local defines" to "private-defines"
- "link externals" to "private-ldflags"
- "deps" to "private-deps" for (test) binaries
- "proto" to "private-proto" for binaries
Improvements:
- consistent variable declaration order:
OS, ARCH, HOST_ARCH, TARGET_ARCH,
CC, CXX, CFLAGS, CXXFLAGS, ADD_CFLAGS, ADD_CXXFLAGS,
AR, ENV, PATH
- use fields close to their definition (in RULES)
- use common expression for binaries and test binaries
- split expression "flags" and "compiler"
... to separate ones for CC and CXX.
- rename "transition" to "deps-transition"
... to avoid conflicts with other transitions.
- support "defaults-transition" for CC expressions
Implement:
- "cflags" for libraries
- "private-cflags" for (test) binaries
- "private-defines" for test binaries
- "private-ldflags" for test binaries
- (public) "defines" for libraries
|
|
... in favor of the "tree" built-in rule.
|
|
|
|
... so that for every construct supported in rules there is
an analogous one as a built-in rule to allow ad-hoc constructions
without having to write a rule (even though writing a rule is
recommended for everything occuring more than once):
- the "generic" rule allows an ad-hoc ACTION,
- the "file_gen" rule allows an ad-hoc BLOB,
- the "tree" rule allows an an ad-hoc TREE, and
- the "configure" rule allows an ad-hoc configuration transition.
|
|
The built-in rule configure carries out a full configuration
transition. While this is useful in quite a few situations,
care has to be taken to avoid conflicts on dependencies also
used in other ways by the calling target. Document this more
clearly in the documentation.
|
|
|
|
... and thus allowing the "business logic" in the configuration
target (e.g., setting defaults and derived options) to be shared
by many targets.
|
|
... when introducing export targets. In this way, the user
has a way to take a meaningful decission on which variables
to export.
|
|
While building from source as certain advantages, there are also
good reasons to use pre-installed dependencies. Document this in the
tutorial to avoid wrong impressions readers might have otherwise.
|
|
|
|
Staging is quite a fundamental concept of just. Therefore, introduce
it early in the tutorial. In this way, it also becomes obvious, why
only targets are requested and files are not installed by default.
|
|
... as an way of directly obtaining an artifact without
an additional detour through the file system.
|
|
When the tutorial references blob identifiers in the output,
also immediately explain the syntax. Also emphasize the possible
abbreviations made possible by b9880e8ecdce02f047dfb1d19de5f1ed07a82ac6
given that they are typically used in practise.
Co-authored-by: Klaus Aehlig <aehlig@linta.de>
|
|
|
|
|
|
|
|
|
|
|
