|Age||Commit message (Collapse)||Author|
Add support for pushing the current branch in all linked subprojects in
a given config. If they are not on the same branch, an error is thrown.
The branches are pushed as linaro-local/$user/$branch, where $branch is
the local name of the branch and $user is the user as seen in
LLVM_GITUSER (we might want to change to a more intelligent way to get
the user in the future).
We achieve this by adding a new method to LLVMSourceConfig:
for_each_enabled, which takes an action and applies it to all the
enabled subprojects. If an exception is thrown by the action, it is
rethrown by the action as a RuntimeError specifying which project the
action was being applied to. Note that this does not behave like a
transaction - the action may have been applied to some of the projects
already, and there's no way to undo it. It's also a bit difficult to
tell which projects the action was applied on (in the future we should
probably log that info).
We also provide an action that simply pushes the current branch to
origin with the updated name. This makes sure the remote branch will
live in an isolated namespace where it won't conflict with other
We also update some of the internals of LLVMSourceConfig to throw
exceptions if some of the subprojects that are linked are not worktrees
on the same branch as LLVM. In the past they were just ignored, but that
doesn't seem like a sane default anymore.
Before this patch, we had an LLVM_ROOT directory which contained the
repos and a series of environments (worktrees + build dicretories).
However, there is no good reason to have such a rigid layout, and in
fact it prevents us from sharing the repos in any meaningful way.
This patch removes LLVM_ROOT and instead introduces two command line
parameters, repos and env, which represent the path to the directory
containing the LLVM repositories and respectively the path to the
environment that we intend to modify. The two paths may be completely
independent. A side effect of this is that we can now also have
different environments in different, unrelated locations (whereas
previously they had to be siblings in LLVM_ROOT).
For the time being, both parameters are compulsory (not only for
llvm-projects, but for all subcommands). There may be situations where
we can get away with only one of them (e.g. `llvm-projs <env>`, which
just lists the projects enabled in the given <env> - it does not need to
know where the repos are in order to do this). There may also be
situations where one of them doesn't make any sense at all (e.g.
`llvm-prepare`, which is not implemented yet in python, only needs the
path to the repos and it would not know what to do with an environment).
Making them optional would require some additional validation logic as
well as more tests, and it feels a bit early on to introduce all that.
It would be nice to have at least one or 2 more subcommands implemented
before we invest time in it.
Add an extra parameter to llvm.py representing the environment that we
want the command to refer to. We then compute the path to the LLVM
source tree based on that and LLVM_ROOT (which is still an environment
variable for the time being).
The bash helper keeps its old interface and uses LLVM_SRC to compute the
environment that it will pass down to llvm.py. We also perform a small
number of drive-by fixes to this helper (e.g. replacing python with
Most of the changes have been made by 2to3. Some manual fiddling was
needed to make sure we're calling python3 instead of just python in the
tests. Two of the helpers in the tests were reworked into proper methods
rather than partials because we had to convert their returned value to
str and this seems like the most straightforward/easy-to-read way.
This is the first step in moving all our scripts to python. For now we keep the
current content of the repo, but we'll start adding a new directory hierarchy
for the python stuff:
* modules: should contain most of the python code, organized as a package that
can be imported by the scripts
* scripts: the scripts themselves, which should be parsing the command line
and calling stuff from 'modules' to do the actual work; can be
broken down into the same categories we had before (helpers, bisect
etc), or we could just have one big pile
* tests: should contain unittests (for the stuff in modules) and command line
interface tests (for the scripts)
The code is heavily using functionality from the tcwg-release-tools repo (which
probably needs to be renamed / reorganized), so you should have that in your
PYTHONPATH when trying to run any of the scripts. To run the tests, just invoke
One of the important changes is that we'll be using python's argparse module to
parse command line flags, which means we'll have to stick to a more traditional
interface for the scripts. In particular, we can't have short options like "+c"
anymore. This isn't much of a problem, because we will keep the bash scripts as
they are and just make them invoke a tool written in python (scripts/llvm.py) to
do the work. The tool will have subcommands for any functionality that we want,
for instance the new interface for adding/removing subprojects is:
llvm.py projects [-a subproject subproject ... subproject]
[-r subproject ... subproject]
The -a and -r options (followed by any number of subprojects) can be used to
selectively enable/disable things. You have to pass the full name of the
subproject (e.g. llvmprojs.py -a clang lld -r libcxx) for it to work. This is
invoked by the llvm-projs bash script, which has the old, more convenient
For now the bash scripts will live in the same directories as they used to, but
after the transition is complete we will want to move them to the scripts
Note that we're also eliding any dashes in the names of the scripts, in keeping
with Python best practices for module names (i.e. using valid Python identifiers