Metadata-Version: 2.1
Name: wst
Version: 0.1.1
Summary: A lightweight tool for managing a workspace of repositories
Home-page: UNKNOWN
Author: Martin Kelly
Author-email: mkelly@xevo.com
License: BSD
Description: # Workspace tool
        `ws` is a lightweight tool for managing a workspace of code repositories. It is
        intended to handle coarse dependencies between projects, building multiple
        projects in the right order and passing the correct flags to each (such as
        `PKG_CONFIG_PATH` and similar). It is not intended to be a full-fledged build
        system, but instead should merely build each project in the right order and with
        the right environment glue. Everything it does can be done by-hand, so rather
        than a replacing existing build tools, it merely automates the tedious task of
        manually specifying `--prefix`, setting env vars, and rebuilding projects in the
        right order when they change.
        
        Note that these tools do not directly handle source code syncing. That job is
        left to [repo](https://code.google.com/archive/p/git-repo/) and similar tools.
        
        ## Dependencies
        `ws` depends on the Python 3 PyYAML, which you can get either with `sudo apt
        install python3-yaml` or via `pip3 install -r requirements.txt` from the top of
        the repository.
        
        ## Installing
        To install `ws`, you can use the `setup.py` script at the top level of the
        repository: `python3 setup.py install <add any custom options here>`. You can
        also use pip: `pip3 install .` from the top of the repository. Finally, if you
        want the installed `ws` to directly symlink into your source directory instead
        of being a one-time copy of the code, use `pip3 install -e .`, which activates
        pip "developer mode". This way, code changes immediately take effect without
        re-running the install step.
        
        ## ws
        The `ws` script is the main point of interaction with your workspace. It assumes
        you have already synced a bunch of code using the `repo` tool and, unless you
        use special options, it assumes you are currently somewhree inside the root of
        the source that `repo` manages. Like `repo` however, you can be anywhere inside
        the root and do not have to be at the very top.
        
        The normal workflow for `ws` is as follows:
        
        ```
        repo init -u MANIFEST-REPO-URL
        repo sync
        ws init
        ws build
        ```
        
        By default, `ws init` will look for a file called `ws-manifest.yaml` at the root
        of the repository containing the `git-repo` manifest (the one we passed `-u`
        into when we called `repo init`). This file contains dependency and build system
        information for the projects that `ws` manages. Note that `ws` does not have to
        manage all the same projects that `repo` manages, but it can. The full format
        for `ws-manifest.yaml` is at the bottom of the README.
        
        If you don't use the `git-repo` tool, you can instead pass in your own ws
        manifest via `ws init -m`. This lets you manage the manifest however you like
        (e.g. submodules, or manually).
        
        ## bash-completion
        If you like bash-completions and typing things fast, you can do:
        ```
        . bash-completion/ws
        ```
        And get auto-completion for ws commands.
        
        ### ws init
        When you run `ws init`, ws creates a `.ws` directory in the current working
        directory. This directory can contain multiple workspaces, but there is always a
        default workspace, which is the one that gets used if you don't specify an
        alternate workspace with the `-w` option. You may want to create multiple
        workspaces to manage multiple build configurations, such as separate debug and
        release builds. However, all workspaces in the same `.ws` directory will still
        operate on the same source code (the repositories configured in
        `ws-manifest.yaml`).
        
        If you specify `-m`, you can manually point to a `ws-manifest.yaml` to use. By
        default, this is relative to a repository containing a git-repo manifest (e.g.
        if you have a `.repo` directory after running `repo init`, then it is relative
        to `.repo/manifests`). If you specify `-s fs`, then it can point
        anywhere on the filesystem instead.
        
        ### ws default
        `ws default` is used to change the default workspace (the one used when you
        don't specify a `-w` option).
        
        ### ws build
        `ws build` is the main command you run. If you specify no arguments, it will
        build every project that repo knows about. If you instead specify a project or
        list of projects, it will build only those, plus any dependencies of them.
        Additionally, `ws` will checksum the source code on a per-repo basis and avoid
        rebuilding anything that hasn't changed. The checksumming logic uses git for
        speed and reliability, so source managed by `ws` has to use git.
        
        ### ws clean
        `ws clean` cleans the specified projects, or all projects if no arguments
        are given. By default, it just runs the clean command for the underlying build
        system (meson, cmake, etc.). If you also use the `-f/--force` switch, it will
        instead remove the entire build directory instead of trusting the underlying
        build system.
        
        ### ws env
        `ws env` allows you to enter the build environment for a given project. If given
        no arguments, it gives you an interactive shell inside the build directory for
        the project. If given arguments, it instead runs the specified command from that
        directory. In both cases, it sets up the right build enviroment so build
        commands you might use will work correctly and you can inspect if something
        seems wrong.
        
        An example use of `ws env` is to manually build something or to tweak the build
        configuration of a given project in a way that `ws` doesn't know how to handle.
        
        ## ws manifest
        The `ws` manifest is a YAML file specifying a few things about the projects `ws`
        manages:
        - What build system they use (currently supports `meson` and `cmake`).
        - What dependencies they have on other projects managed by `ws`.
        - Any special environment variables they need.
        
        The syntax is as follows:
        ```
        some-project:
            build: meson
            deps:
                - gstreamer
                - ...
            env:
                GST_PLUGIN_PATH: ${LIBDIR}/gstreamer-1.0
        
        gstreamer:
            build: meson
            deps:
                - ...
        ```
        
        In this case, `some-project` builds with `meson`, and requires `gstreamer` and
        some other dependencies. In order to find gstreamer plugins, it needs
        `GST_PLUGIN_PATH` set. It uses template syntax to refer to `${LIBDIR}`, which will
        be filled in with the library path for the project.
        
        Here is the complete list of usable template variables:
        ```
        - ${LIBDIR}: the library path for the project (what `LD_LIBRARY_PATH` will be
          set to for the project's build environment.
        - ${PREFIX}: the project's prefix (what you would pass to `--prefix`).
        ```
        
Platform: UNKNOWN
Classifier: Development Status :: 3 - Alpha
Classifier: Environment :: Console
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Natural Language :: English
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Topic :: Software Development :: Build Tools
Requires-Python: >=3
Description-Content-Type: text/markdown
