path: root/scripts
AgeCommit message (Collapse)Author
2017-07-07[llvmpush] Add llvm pushDiana Picus
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 people's branches. 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. Change-Id: I9c917658d65b5d0e7bad3310efce07a0fe5bce5e
2017-05-12Separate the repos from the environmentsDiana Picus
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. Change-Id: Ibc1321d18476c2c4a65b5b05ca3fce3467d72fc3
2017-04-24Remove the need for LLVM_SRC in llvm.pyDiana Picus
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 python3). Change-Id: Ie7a33103969622294e158f83be8b9f57832ef1dc
2017-04-06Move to Python3Diana Picus
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. Change-Id: I74fdc1eaade3c026ee0c3e6bcdf26f8840f259b3
2016-12-15[llvmprojs] Rewrite llvm-projs in pythonDiana Picus
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 check.sh. 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 interface. 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 directory. 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 as names). Change-Id: I9ec08632dbb17464673240d6f6881a90f45d5371