mirror of
https://gitlab.kitware.com/cmake/cmake.git
synced 2026-09-25 04:09:36 +03:00
The container ran a developer's own `hooks/root.sh` and `hooks/user.sh` while the image was built, and nothing of theirs afterwards. A customization that has to start something, or to reach the source tree, had nowhere to run: the tree is not mounted during the build, and the one lifecycle command the configuration used was spoken for by the status report. Run an optional script per phase through `run-hooks.sh`, and offer five: `initialize` on the host, `build` in the image, and `post-create`, `post-start` and `post-attach` in the container. A failing `build` hook fails the image build, because an image whose customizations did not apply is quietly wrong; the rest are reported and otherwise ignored, so that a typo in a personal hook cannot leave its author unable to open the container in order to fix it. The two build hooks become one, running as the container user, who may `sudo`: one hook that reaches either user is simpler to write against than two that each reach one. Every hook is told where it lives, and every hook but the build one is given a directory to keep state in, beside the hooks rather than among them because state is written by whatever they start rather than by hand. `.dockerignore` keeps that directory out of the build context, which state written as `root` would otherwise make unreadable.
CMake Development ***************** This directory contains documentation about development of CMake itself. It is not part of the user documentation distributed with CMake. Contributor Instructions ======================== See `CONTRIBUTING.rst`_ for instructions to contribute changes. The process for contributing changes is the same whether or not one has been invited to participate directly in upstream development. .. _`CONTRIBUTING.rst`: ../../CONTRIBUTING.rst Upstream Development ==================== CMake uses `Kitware's GitLab Instance`_ to manage development, review, and integration of changes. The `CMake Repository`_ holds the integration branches and tags. Upstream development processes are covered by the following documents: * The `CMake Review Process`_ manages integration of changes. * The `CMake Integration Testing`_ infrastructure tests changes before and after merging. .. _`Kitware's GitLab Instance`: https://gitlab.kitware.com .. _`CMake Repository`: https://gitlab.kitware.com/cmake/cmake .. _`CMake Review Process`: review.rst .. _`CMake Integration Testing`: integration-testing.rst Developer Documentation ======================= CMake developer documentation is provided by the following documents: * The `CMake Dev Container Guide`_. * The `CMake Source Code Guide`_. * The `CMake Documentation Guide`_. * The `CMake Testing Guide`_. * The `CMake Experimental Features Guide`_. * The `CMake Debugging Guide`_. * The `CMake Diagnostics Guide`_. .. _`CMake Dev Container Guide`: devcontainer.rst .. _`CMake Source Code Guide`: source.rst .. _`CMake Documentation Guide`: documentation.rst .. _`CMake Testing Guide`: testing.rst .. _`CMake Experimental Features Guide`: experimental.rst .. _`CMake Debugging Guide`: debug.rst .. _`CMake Diagnostics Guide`: diagnostics.rst Maintainer Documentation ======================== CMake maintainer documentation is provided by the following documents: * The `CMake Maintainer Guide`_. .. _`CMake Maintainer Guide`: maint.rst