Files
cmake/Help/dev
Taylor Braun-Jones f1b6b3a6f0 devcontainer: Run local customization hooks through the container's life
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.
2026-09-09 18:35:57 -04:00
..
2026-03-21 08:35:50 +11:00

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