[Notes] [Git][BuildStream/buildstream][willsalmon/outOfSourecBuild] 17 c

Will Salmon pushed to branch willsalmon/outOfSourecBuild at BuildStream / buildstream

Commits:

d827dfae
by Angelos Evripiotis at 2018-10-09T09:12:45Z
```
contributing.rst: end lines with punctuation
```

9590e8ae

by Angelos Evripiotis at 2018-10-09T09:12:45Z

contributing.rst: fix whitespace

No tabs, no lines of only horizontal whitespace.

6d02e269
by Angelos Evripiotis at 2018-10-09T09:12:45Z
```
contributing.rst: fix typo of 'get_count'
```

3ed26a47

by Angelos Evripiotis at 2018-10-09T09:12:45Z

contributing.rst: de-paren subclass example

It seems easier to read when separated into two sentences.

5b22d850
by Angelos Evripiotis at 2018-10-09T09:12:45Z
```
contributing.rst: no spaces before '?'
```

ac0776f8

by Tristan Van Berkom at 2018-10-09T09:36:33Z

Merge branch 'aevri/contributing_fixups' into 'master'

Minor fixups to contributing.rst

See merge request BuildStream/buildstream!866

885bd946

by Tristan Van Berkom at 2018-10-09T09:39:24Z

CONTRIBUTING.rst: Added note about sphinx supporting docstrings on instance variables

Python does not natively support this, but sphinx does parse them and includes
these in the generated documentation.

120d8c73

by Tristan Van Berkom at 2018-10-09T09:45:23Z

CONTRIBUTING.rst: Fix typos in previous commit.

Ooops, that was done far too quickly.

cda1354c

by Chandan Singh at 2018-10-10T00:17:51Z

doc: Add new document about Docker integrations

Add a new section under "Additional writings" section about how
BuildStream integrates with Docker. At present, this section includes
only two sections:

- "Run BuildStream inside Docker", that refers to existing instructions
for doing so
- "Generate Docker images", that adds instructions for using the newly
added `contrib/bst-docker-import` script

In future, this document can be extended to include the following
things:

- Importing Docker sources via `docker` source plugin - if/when the
Docker source plguin is moved from bst-external to BuildStream proper
- A Docker sandbox, if/when that is added

dd472d95

by Chandan Singh at 2018-10-10T00:18:17Z

NEWS: Add entry about contrib/bst-docker-import

As suggested in
https://gitlab.com/BuildStream/buildstream/merge_requests/857#note_106809743,
add a NEWS entry for `contrib/bst-docker-import` that was added
recently.

35ac26a7

by Chandan Singh at 2018-10-10T00:59:17Z

Merge branch 'chandan/bst-and-docker' into 'master'

Add documentation and NEWS entry about bst-docker-import

See merge request BuildStream/buildstream!864

c6298bc0

by William Salmon at 2018-10-10T09:16:24Z

Sandbox: CWD was not being created for workspaces

The code was creating the cwd folder but when the workspace was
mounted in to the buildroot it was hiding the folder created in it
behind the bind mounted workspace.

However by using the bubblewarp `--dir` directive to ensure that cwd
exists we can cover both workspace and non workspace situations with
the same method.

For issue #512 in Gitlab.

836727ba

by William Salmon at 2018-10-10T09:16:29Z

New Integration test for workspace command-subdir

Build stream was only creating command-subdir for non workspace builds
this has now been fixed, and this regression test should support the
feature.

For issue #512 in Gitlab.

8f865d18

by William Salmon at 2018-10-10T09:16:36Z

Add conf-root variable to builds

Adding the conf-root variable makes creating out of source builds
slightly easier.

For issue #512 in Gitlab.

be9208a1

by William Salmon at 2018-10-10T14:06:06Z

Added tests for conf-root variable

For issue #512 in Gitlab.

01e1d116

by William Salmon at 2018-10-10T14:17:24Z

Extended the Documentation to cover out of source builds

For issue #512 in Gitlab.

4651e4b0

by William Salmon at 2018-10-10T14:17:25Z

Added a news item for building out of the source directory

For issue #512 in Gitlab.

24 changed files:

CONTRIBUTING.rst
NEWS
buildstream/_versions.py
buildstream/buildelement.py
buildstream/data/projectconfig.yaml
buildstream/plugins/elements/autotools.yaml
buildstream/plugins/elements/cmake.yaml
buildstream/plugins/elements/distutils.yaml
buildstream/plugins/elements/meson.yaml
buildstream/plugins/elements/pip.yaml
buildstream/plugins/elements/qmake.yaml
buildstream/sandbox/_sandboxbwrap.py
buildstream/sandbox/_sandboxchroot.py
buildstream/sandbox/sandbox.py
buildstream/source.py
+ doc/source/additional_docker.rst
doc/source/core_additional.rst
tests/format/variables.py
tests/integration/autotools.py
tests/integration/cmake.py
+ tests/integration/project/elements/autotools/amhelloconfroot.bst
+ tests/integration/project/elements/cmake/cmakeconfroothello.bst
+ tests/integration/project/elements/workspace/workspace-commanddir.bst
tests/integration/workspace.py

Changes:

CONTRIBUTING.rst

@@ -14,7 +14,7 @@ if no issue already exists.
  For policies on how to submit an issue and how to use our project labels,
  we recommend that you read the `policies guide
 -<https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/BuildStream_policies.md>`_
 +<https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/BuildStream_policies.md>`_.
  .. _contributing_fixing_bugs:
@@ -270,6 +270,11 @@ comments and docstrings.
      *Since: 1.2*
      """
 +.. note::
++
 +   Python does not support docstrings on instance variables, but sphinx does
 +   pick them up and includes them in the generated documentation.
++
  **Internal instance variable**::
    def __init__(self, context, element):
@@ -404,7 +409,7 @@ on a Python class in BuildStream::
           # Implementation of the "frobbish" abstract method
           # defined by the parent Bar class.
+          #
 -	 return True
 +         return True
        ################################################
        #                 Public Methods               #
@@ -445,7 +450,7 @@ on a Python class in BuildStream::
        # Returns:
        #    (int): The count of this foo
+       #
 -      def set_count(self, count):
 +      def get_count(self, count):
            return self._count
@@ -459,7 +464,7 @@ on a Python class in BuildStream::
        #       Even though these are private implementation
        #       details, they still MUST have API documenting
        #       comments on them.
+-
++
        # _do_frobbing()
+       #
        # Does the actual frobbing
@@ -494,10 +499,10 @@ reference on how the PEP-8 defines public and non-public.
    A private symbol must be denoted by a leading underscore.
 -* When a class can have subclasses (for example, the ``Sandbox`` or ``Platform``
 +* When a class can have subclasses, then private symbols should be denoted
 +  by two leading underscores. For example, the ``Sandbox`` or ``Platform``
    classes which have various implementations, or the ``Element`` and ``Source``
 -  classes which plugins derive from), then private symbols should be denoted
 -  by two leading underscores.
 +  classes which plugins derive from.
    The double leading underscore naming convention invokes Python's name
    mangling algorithm which helps prevent namespace collisions in the case
@@ -536,7 +541,7 @@ In order to disambiguate between:
  * Symbols which are publicly accessible details of the ``Element`` class, can
    be accessed by BuildStream internals, but must remain hidden from the
 -  *"Public API Surface"*
 +  *"Public API Surface"*.
  * Symbols which are private to the ``Element`` class, and cannot be accessed
    from outside of the ``Element`` class at all.
@@ -586,7 +591,7 @@ is found at ``_artifactcache/artifactcache.py``.
  Imports
  ~~~~~~~
 -Module imports inside BuildStream are done with relative ``.`` notation
 +Module imports inside BuildStream are done with relative ``.`` notation:
  **Good**::
@@ -628,12 +633,12 @@ which exposes an instance variable is the only one in control of the value of th
  variable.
  * If an instance variable is public and must be modified; then it must be
 -  modified using a :ref:`mutator <contributing_accessor_mutator>`
 +  modified using a :ref:`mutator <contributing_accessor_mutator>`.
  * Ideally for better encapsulation, all object state is declared as
    :ref:`private instance variables <contributing_public_and_private>` and can
    only be accessed by external classes via public :ref:`accessors and mutators
 -  <contributing_accessor_mutator>`
 +  <contributing_accessor_mutator>`.
  .. note::
@@ -720,10 +725,10 @@ In BuildStream, we use the term *"Abstract Method"*, to refer to
  a method which **can** be overridden by a subclass, whereas it
  is **illegal** to override any other method.
 -* Abstract methods are allowed to have default implementations
 +* Abstract methods are allowed to have default implementations.
  * Subclasses are not allowed to redefine the calling signature
 -  of an abstract method, or redefine the API contract in any way
 +  of an abstract method, or redefine the API contract in any way.
  * Subclasses are not allowed to override any other methods.
@@ -798,7 +803,7 @@ BstError parameters
  When raising ``BstError`` class exceptions, there are some common properties
  which can be useful to know about:
 -* **message:** The brief human readable error, will be formatted on one line in the frontend
 +* **message:** The brief human readable error, will be formatted on one line in the frontend.
  * **detail:** An optional detailed human readable message to accompany the **message** summary
    of the error. This is often used to recommend the user some course of action, or to provide
@@ -974,9 +979,9 @@ symbols to a minimum, this is important for both
  When anyone visits a file, there are two levels of comprehension:
 -* What do I need to know in order to *use* this object
 +* What do I need to know in order to *use* this object.
 -* What do I need to know in order to *modify* this object
 +* What do I need to know in order to *modify* this object.
  For the former, we want the reader to understand with as little effort
  as possible, what the public API contract is for a given object and consequently,
@@ -1001,9 +1006,9 @@ well documented and minimal.
  When adding new API to a given object for a new purpose, consider whether
  the new API is in any way redundant with other API (should this value now
 -go into the constructor, since we use it more than once ? could this
 +go into the constructor, since we use it more than once? could this
  value be passed along with another function, and the other function renamed,
 -to better suit the new purposes of this module/object ?) and repurpose
 +to better suit the new purposes of this module/object?) and repurpose
  the outward facing API of an object as a whole every time.
@@ -1183,7 +1188,7 @@ The BuildStream documentation style is as follows:
  * Cross references should be of the form ``:role:`target```.
    * Explicit anchors can be declared as ``.. _anchor_name:`` on a line by itself.
+-
++
    * To cross reference arbitrary locations with, for example, the anchor ``anchor_name``,
      always provide some explicit text in the link instead of deriving the text from
      the target, e.g.: ``:ref:`Link text <anchor_name>```.
@@ -1266,23 +1271,23 @@ Documentation Examples
  The examples section of the documentation contains a series of standalone
  examples, here are the criteria for an example addition.
 -* The example has a ``${name}``
 +* The example has a ``${name}``.
 -* The example has a project users can copy and use
 +* The example has a project users can copy and use.
 -  * This project is added in the directory ``doc/examples/${name}``
 +  * This project is added in the directory ``doc/examples/${name}``.
 -* The example has a documentation component
 +* The example has a documentation component.
    * This is added at ``doc/source/examples/${name}.rst``
    * A reference to ``examples/${name}`` is added to the toctree in ``doc/source/examples.rst``
    * This documentation discusses the project elements declared in the project and may
 -    provide some BuildStream command examples
 -  * This documentation links out to the reference manual at every opportunity
 +    provide some BuildStream command examples.
 +  * This documentation links out to the reference manual at every opportunity.
 -* The example has a CI test component
 +* The example has a CI test component.
 -  * This is an integration test added at ``tests/examples/${name}``
 +  * This is an integration test added at ``tests/examples/${name}``.
    * This test runs BuildStream in the ways described in the example
      and assert that we get the results which we advertize to users in
      the said examples.
@@ -1309,17 +1314,17 @@ The ``.run`` file format is just another YAML dictionary which consists of a
  Each *command* is a dictionary, the members of which are listed here:
 -* ``directory``: The input file relative project directory
 +* ``directory``: The input file relative project directory.
 -* ``output``: The input file relative output html file to generate (optional)
 +* ``output``: The input file relative output html file to generate (optional).
  * ``fake-output``: Don't really run the command, just pretend to and pretend
    this was the output, an empty string will enable this too.
 -* ``command``: The command to run, without the leading ``bst``
 +* ``command``: The command to run, without the leading ``bst``.
  * ``shell``: Specifying ``True`` indicates that ``command`` should be run as
 -  a shell command from the project directory, instead of a bst command (optional)
 +  a shell command from the project directory, instead of a bst command (optional).
  When adding a new ``.run`` file, one should normally also commit the new
  resulting generated ``.html`` file(s) into the ``doc/source/sessions-stored/``
@@ -1417,7 +1422,7 @@ a subdirectory beside your test in which to store data.
  When creating a test that needs data, use the datafiles extension
  to decorate your test case (again, examples exist in the existing
  tests for this), documentation on the datafiles extension can
 -be found here: https://pypi.python.org/pypi/pytest-datafiles
 +be found here: https://pypi.python.org/pypi/pytest-datafiles.
  Tests that run a sandbox should be decorated with::

NEWS

@@ -24,6 +24,12 @@ buildstream 1.3.1
    o Add new `pip` source plugin for downloading python packages using pip,
      based on requirements files from previous sources.
 +  o Generate Docker images from built artifacts using
 +    `contrib/bst-docker-import` script.
++
 +  o Added Documentation on how to create out of source builds. This includes the
 +    new the `conf-root` variable to make the process easier. And there has been
 +    a bug fix to workspaces so they can be build in workspaces too.
  =================
  buildstream 1.1.5

buildstream/_versions.py

@@ -23,7 +23,7 @@
  # This version is bumped whenever enhancements are made
  # to the `project.conf` format or the core element format.
+ #
 -BST_FORMAT_VERSION = 16
 +BST_FORMAT_VERSION = 17
  # The base BuildStream artifact version

buildstream/buildelement.py

@@ -23,6 +23,48 @@ BuildElement - Abstract class for build elements
  The BuildElement class is a convenience element one can derive from for
  implementing the most common case of element.
 +Built-in functionality
 +----------------------
++
 +The BuildElement base class provides built in functionality that could be
 +overridden by the individual plugins.
++
 +This section will give a brief summary of how some of the common features work,
 +some of them or the variables they use will be further detailed in the following
 +sections.
++
 +* Location for running commands
++
 + The ``command-subdir`` variable sets where the build commands will be executed,
 + if the directory does not exist it will be created, it is defined relative to
 + the buildroot.
++
 +* Location for configuring the project
++
 + The ``conf-root`` is defined by default as ``.`` and is the location that
 + specific build element can use to look for build configuration files, currently
 + autotools, cmake, distutils, meson, pip and qmake use this.
++
 + The configuration commands are run in ``command-subdir`` and by default
 + ``conf-root`` is ``.`` so if ``conf-root`` is not set the configuration files
 + in ``command-subdir`` will be used.
++
 + By setting ``conf-root`` to ``"%{build-root}/Source/conf_location"`` and your
 + source elements ``directory`` variable to ``Source`` then the configuration
 + files in the directory ``conf_location`` with in your Source will be used.
 + However the location where your configuration command will be run will still
 + be wherever you set your ``command-subdir`` to be.
++
 +.. note::
++
 +   The ``conf-root`` variable is available since :ref:`format version 17 <project_format_version>`
++
 +* Install Location
++
 +  You should not change the ``install-root`` variable as it is a special
 +  writeable location in the sandbox but it is useful when writing custom
 +  install instructions as it may need to be supplied as the ``DESTDIR``, please
 +  see the cmake build element for example.
  Abstract method implementations
  -------------------------------

buildstream/data/projectconfig.yaml

@@ -38,6 +38,9 @@ variables:
    # normally staged
    build-root: /buildstream/%{project-name}/%{element-name}
 +  # Indicates where the build system should look for configuration files
 +  conf-root: .
++
    # Indicates the build installation directory in the sandbox
    install-root: /buildstream-install

buildstream/plugins/elements/autotools.yaml

@@ -6,11 +6,11 @@ variables:
      export NOCONFIGURE=1;
      if [ -x %{conf-cmd} ]; then true;
 -    elif [ -x autogen ]; then ./autogen;
 -    elif [ -x autogen.sh ]; then ./autogen.sh;
 -    elif [ -x bootstrap ]; then ./bootstrap;
 -    elif [ -x bootstrap.sh ]; then ./bootstrap.sh;
 -    else autoreconf -ivf;
 +    elif [ -x %{conf-root}/autogen ]; then %{conf-root}/autogen;
 +    elif [ -x %{conf-root}/autogen.sh ]; then %{conf-root}/autogen.sh;
 +    elif [ -x %{conf-root}/bootstrap ]; then %{conf-root}/bootstrap;
 +    elif [ -x %{conf-root}/bootstrap.sh ]; then %{conf-root}/bootstrap.sh;
 +    else autoreconf -ivf %{conf-root};
      fi
    # Project-wide extra arguments to be passed to `configure`
@@ -22,7 +22,8 @@ variables:
    # For backwards compatibility only, do not use.
    conf-extra: ''
 -  conf-cmd: ./configure
 +  conf-cmd: "%{conf-root}/configure"
++
    conf-args: |
      --prefix=%{prefix} \

buildstream/plugins/elements/cmake.yaml

@@ -23,7 +23,7 @@ variables:
    cmake: |
 -    cmake -B%{build-dir} -H. -G"%{generator}" %{cmake-args}
 +    cmake -B%{build-dir} -H"%{conf-root}" -G"%{generator}" %{cmake-args}
    make: cmake --build %{build-dir} -- ${JOBS}
    make-install: env DESTDIR="%{install-root}" cmake --build %{build-dir} --target install

buildstream/plugins/elements/distutils.yaml

@@ -8,7 +8,7 @@ variables:
    python-build: |
 -    %{python} setup.py build
 +    %{python} %{conf-root}/setup.py build
    install-args: |
@@ -17,7 +17,7 @@ variables:
    python-install: |
 -    %{python} setup.py install %{install-args}
 +    %{python} %{conf-root}/setup.py install %{install-args}
  config:

buildstream/plugins/elements/meson.yaml

@@ -28,7 +28,7 @@ variables:
      --mandir=%{mandir} \
      --infodir=%{infodir} %{meson-extra} %{meson-global} %{meson-local}
 -  meson: meson %{build-dir} %{meson-args}
 +  meson: meson %{conf-root} %{build-dir} %{meson-args}
    ninja: |
      ninja -j ${NINJAJOBS} -C %{build-dir}

buildstream/plugins/elements/pip.yaml

@@ -14,7 +14,7 @@ config:
+   #
    install-commands:
    - |
 -    %{pip} install --no-deps --root=%{install-root} --prefix=%{prefix} .
 +    %{pip} install --no-deps --root=%{install-root} --prefix=%{prefix} %{conf-root}
    # Commands for stripping debugging information out of
    # installed binaries

buildstream/plugins/elements/qmake.yaml

@@ -2,7 +2,7 @@
  variables:
 -  qmake: qmake -makefile
 +  qmake: qmake -makefile %{conf-root}
    make: make
    make-install: make -j1 INSTALL_ROOT="%{install-root}" install

buildstream/sandbox/_sandboxbwrap.py

@@ -108,9 +108,6 @@ class SandboxBwrap(Sandbox):
              bwrap_command += ['--unshare-uts', '--hostname', 'buildstream']
              bwrap_command += ['--unshare-ipc']
 -        if cwd is not None:
 -            bwrap_command += ['--chdir', cwd]
+-
          # Give it a proc and tmpfs
          bwrap_command += [
              '--proc', '/proc',
@@ -151,6 +148,10 @@ class SandboxBwrap(Sandbox):
          if flags & SandboxFlags.ROOT_READ_ONLY:
              bwrap_command += ["--remount-ro", "/"]
 +        if cwd is not None:
 +            bwrap_command += ['--dir', cwd]
 +            bwrap_command += ['--chdir', cwd]
++
          # Set UID and GUI
          if self.user_ns_available:
              bwrap_command += ['--unshare-user']
@@ -179,11 +180,6 @@ class SandboxBwrap(Sandbox):
          with ExitStack() as stack:
              stack.enter_context(mount_map.mounted(self))
 -            # Ensure the cwd exists
 -            if cwd is not None:
 -                workdir = os.path.join(root_mount_source, cwd.lstrip(os.sep))
 -                os.makedirs(workdir, exist_ok=True)
+-
              # If we're interactive, we want to inherit our stdin,
              # otherwise redirect to /dev/null, ensuring process
              # disconnected from terminal.

buildstream/sandbox/_sandboxchroot.py

@@ -100,9 +100,8 @@ class SandboxChroot(Sandbox):
              # Ensure the cwd exists
              if cwd is not None:
 -                workdir = os.path.join(root_mount_source, cwd.lstrip(os.sep))
 +                workdir = os.path.join(rootfs, cwd.lstrip(os.sep))
                  os.makedirs(workdir, exist_ok=True)
+-
              status = self.chroot(rootfs, command, stdin, stdout,
                                   stderr, cwd, env, flags)

buildstream/sandbox/sandbox.py

@@ -223,7 +223,9 @@ class Sandbox():
          .. note::
             The optional *cwd* argument will default to the value set with
 -           :func:`~buildstream.sandbox.Sandbox.set_work_directory`
 +           :func:`~buildstream.sandbox.Sandbox.set_work_directory` and this
 +           function must make sure the directory will be created if it does
 +           not exist yet, even if a workspace is being used.
          """
          raise ImplError("Sandbox of type '{}' does not implement run()"
                          .format(type(self).__name__))

buildstream/source.py

@@ -20,6 +20,19 @@
  Source - Base source class
  ==========================
 +Built-in functionality
 +----------------------
++
 +The Source base class provides built in functionality that could be overridden
 +by the individual plugins.
++
 +* Directory
++
 +  The ``directory`` variable can be set for all sources of a type in project.conf
 +  or per source within a element.
++
 +  This sets the location with in the build root that the content of the source
 +  will be loaded in to. If the location dose not exist it will be created.
  .. _core_source_abstract_methods:

doc/source/additional_docker.rst

++
 +.. _bst_and_docker:
++
++
 +BuildStream and Docker
 +======================
++
 +BuildStream integrates with Docker in multiple ways. Here are some ways in
 +which these integrations work.
++
 +Run BuildStream inside Docker
 +-----------------------------
++
 +Refer to the :ref:`BuildStream inside Docker <docker>` documentation for
 +instructions on how to run BuildStream as a Docker container.
++
 +Generate Docker images
 +----------------------
++
 +The
 +`bst-docker-import script <https://gitlab.com/BuildStream/buildstream/blob/master/contrib/bst-docker-import>`_
 +can be used to generate a Docker image from built artifacts.
++
 +You can download it and make it executable like this:
++
 +.. code:: bash
++
 +  mkdir -p ~/.local/bin
 +  curl --get https://gitlab.com/BuildStream/buildstream/raw/master/contrib/bst-docker-import > ~/.local/bin/bst-docker-import
 +  chmod +x ~/.local/bin/bst-docker-import
++
 +Check if ``~/.local/bin`` appears in your PATH environment variable -- if it
 +doesn't, you should
 +`edit your ~/.profile so that it does <https://stackoverflow.com/questions/14637979/>`_.
++
 +Once the script is available in your PATH and assuming you have Docker
 +installed, you can start using the ``bst-docker-import`` script. Here is a
 +minimal example to generate an image called ``bst-hello`` from an element
 +called ``hello.bst`` assuming it is already built:
++
 +.. code:: bash
++
 +  bst-docker-import -t bst-hello hello.bst
++
 +This script can also be used if you are running BuildStream inside Docker. In
 +this case, you will need to supply the command that you are using to run
 +BuildStream using the ``-c`` option.  If you are using the
 +`bst-here wrapper script <https://gitlab.com/BuildStream/buildstream/blob/master/contrib/bst-here>`_,
 +you can achieve the same results as the above example like this:
++
 +.. code:: bash
++
 +  bst-docker-import -c bst-here -t bst-hello hello.bst

doc/source/core_additional.rst

@@ -8,3 +8,4 @@ Additional writings
     additional_cachekeys
     additional_sandboxing
 +   additional_docker

tests/format/variables.py

@@ -19,10 +19,10 @@ DATA_DIR = os.path.join(
  @pytest.mark.parametrize("target,varname,expected", [
      ('autotools.bst', 'make-install', "make -j1 DESTDIR=\"/buildstream-install\" install"),
      ('cmake.bst', 'cmake',
 -     "cmake -B_builddir -H. -G\"Unix Makefiles\" -DCMAKE_INSTALL_PREFIX:PATH=\"/usr\" \\\n" +
 +     "cmake -B_builddir -H\".\" -G\"Unix Makefiles\" " + "-DCMAKE_INSTALL_PREFIX:PATH=\"/usr\" \\\n" +
       "-DCMAKE_INSTALL_LIBDIR=lib   "),
      ('distutils.bst', 'python-install',
 -     "python3 setup.py install --prefix \"/usr\" \\\n" +
 +     "python3 ./setup.py install --prefix \"/usr\" \\\n" +
       "--root \"/buildstream-install\""),
      ('makemaker.bst', 'configure', "perl Makefile.PL PREFIX=/buildstream-install/usr"),
      ('modulebuild.bst', 'configure', "perl Build.PL --prefix \"/buildstream-install/usr\""),
@@ -45,10 +45,10 @@ def test_defaults(cli, datafiles, tmpdir, target, varname, expected):
  @pytest.mark.parametrize("target,varname,expected", [
      ('autotools.bst', 'make-install', "make -j1 DESTDIR=\"/custom/install/root\" install"),
      ('cmake.bst', 'cmake',
 -     "cmake -B_builddir -H. -G\"Ninja\" -DCMAKE_INSTALL_PREFIX:PATH=\"/opt\" \\\n" +
 +     "cmake -B_builddir -H\".\" -G\"Ninja\" " + "-DCMAKE_INSTALL_PREFIX:PATH=\"/opt\" \\\n" +
       "-DCMAKE_INSTALL_LIBDIR=lib   "),
      ('distutils.bst', 'python-install',
 -     "python3 setup.py install --prefix \"/opt\" \\\n" +
 +     "python3 ./setup.py install --prefix \"/opt\" \\\n" +
       "--root \"/custom/install/root\""),
      ('makemaker.bst', 'configure', "perl Makefile.PL PREFIX=/custom/install/root/opt"),
      ('modulebuild.bst', 'configure', "perl Build.PL --prefix \"/custom/install/root/opt\""),

tests/integration/autotools.py

@@ -38,6 +38,30 @@ def test_autotools_build(cli, tmpdir, datafiles):
                                 '/usr/share/doc/amhello/README'])
 +# Test that an autotools build 'works' - we use the autotools sample
 +# amhello project for this.
 +@pytest.mark.integration
 +@pytest.mark.datafiles(DATA_DIR)
 +def test_autotools_confroot_build(cli, tmpdir, datafiles):
 +    project = os.path.join(datafiles.dirname, datafiles.basename)
 +    checkout = os.path.join(cli.directory, 'checkout')
 +    element_name = 'autotools/amhelloconfroot.bst'
++
 +    result = cli.run(project=project, args=['build', element_name])
 +    assert result.exit_code == 0
++
 +    result = cli.run(project=project, args=['checkout', element_name, checkout])
 +    assert result.exit_code == 0
++
 +    assert_contains(checkout, ['/usr', '/usr/lib', '/usr/bin',
 +                               '/usr/share', '/usr/lib/debug',
 +                               '/usr/lib/debug/usr', '/usr/lib/debug/usr/bin',
 +                               '/usr/lib/debug/usr/bin/hello',
 +                               '/usr/bin/hello', '/usr/share/doc',
 +                               '/usr/share/doc/amhello',
 +                               '/usr/share/doc/amhello/README'])
++
++
  # Test running an executable built with autotools
  @pytest.mark.datafiles(DATA_DIR)
  def test_autotools_run(cli, tmpdir, datafiles):

tests/integration/cmake.py

@@ -32,6 +32,24 @@ def test_cmake_build(cli, tmpdir, datafiles):
                                 '/usr/lib/debug/usr/bin/hello'])
 +@pytest.mark.datafiles(DATA_DIR)
 +def test_cmake_confroot_build(cli, tmpdir, datafiles):
 +    project = os.path.join(datafiles.dirname, datafiles.basename)
 +    checkout = os.path.join(cli.directory, 'checkout')
 +    element_name = 'cmake/cmakeconfroothello.bst'
++
 +    result = cli.run(project=project, args=['build', element_name])
 +    assert result.exit_code == 0
++
 +    result = cli.run(project=project, args=['checkout', element_name, checkout])
 +    assert result.exit_code == 0
++
 +    assert_contains(checkout, ['/usr', '/usr/bin', '/usr/bin/hello',
 +                               '/usr/lib/debug', '/usr/lib/debug/usr',
 +                               '/usr/lib/debug/usr/bin',
 +                               '/usr/lib/debug/usr/bin/hello'])
++
++
  @pytest.mark.datafiles(DATA_DIR)
  def test_cmake_run(cli, tmpdir, datafiles):
      project = os.path.join(datafiles.dirname, datafiles.basename)

tests/integration/project/elements/autotools/amhelloconfroot.bst

 +kind: autotools
 +description: Autotools test
++
 +depends:
 +- base.bst
++
 +sources:
 +- kind: tar
 +  url: project_dir:/files/amhello.tar.gz
 +  ref: 9ba123fa4e660929e9a0aa99f0c487b7eee59c5e7594f3284d015640b90f5590
 +  directory: SourceFile
++
 +variables:
 +  conf-root: "%{build-root}/SourceFile"
 +  command-subdir: build

tests/integration/project/elements/cmake/cmakeconfroothello.bst

 +kind: cmake
 +description: Cmake test
++
 +depends:
 +  - base.bst
++
 +sources:
 +  - kind: tar
 +    directory: Source
 +    url: project_dir:/files/cmakehello.tar.gz
 +    ref: 508266f40dbc5875293bd24c4e50a9eb6b88cbacab742033f7b92f8c087b64e5
++
 +variables:
 +  conf-root: "%{build-root}/Source"
 +  command-subdir: build

tests/integration/project/elements/workspace/workspace-commanddir.bst

 +kind: manual
 +description: Workspace mount test
++
 +depends:
 +  - filename: base.bst
 +    type: build
++
 +sources:
 +  - kind: local
 +    path: files/workspace-mount-src/
++
 +variables:
 +  command-subdir: build
++
 +config:
 +  build-commands:
 +    - cc -c ../hello.c

tests/integration/workspace.py

@@ -32,6 +32,23 @@ def test_workspace_mount(cli, tmpdir, datafiles):
      assert os.path.exists(os.path.join(cli.directory, 'workspace'))
 +@pytest.mark.integration
 +@pytest.mark.datafiles(DATA_DIR)
 +def test_workspace_commanddir(cli, tmpdir, datafiles):
 +    project = os.path.join(datafiles.dirname, datafiles.basename)
 +    workspace = os.path.join(cli.directory, 'workspace')
 +    element_name = 'workspace/workspace-commanddir.bst'
++
 +    res = cli.run(project=project, args=['workspace', 'open', element_name, workspace])
 +    assert res.exit_code == 0
++
 +    res = cli.run(project=project, args=['build', element_name])
 +    assert res.exit_code == 0
++
 +    assert os.path.exists(os.path.join(cli.directory, 'workspace'))
 +    assert os.path.exists(os.path.join(cli.directory, 'workspace', 'build'))
++
++
  @pytest.mark.integration
  @pytest.mark.datafiles(DATA_DIR)
  def test_workspace_updated_dependency(cli, tmpdir, datafiles):

[Notes] [Git][BuildStream/buildstream][willsalmon/outOfSourecBuild] 17 commits: contributing.rst: end lines with punctuation

Will Salmon pushed to branch willsalmon/outOfSourecBuild at BuildStream / buildstream

Commits:

24 changed files:

Changes: