build2 Project Roadmap
The aim of this document is to lay out the current
build2 project roadmap.
We divide all planned features or areas of work into three categories: "Strategic/Foundational", "Important", and "Nice to Have". Normally, we try to make progress on at least one Strategic/Foundational area in every release, though sometimes we have cleanup releases where the primarily focus is on fixing bugs, paying off accumulated technical debt, etc.
The two common labels you will find next to some features are [WIP]
meaning the feature is being actively worked on (and you are welcome to start
experimenting with it) as well as [HELP] meaning the feature needs help
from the broader community in the form of feedback, expertise (for example,
knowledge and experience using a language or tool we are trying to support),
and/or actual implementation before it can go forward. Note that this doesn't
mean we don't want help on other features, of course. See also
Contributing for other ways
to contribute to the
Build system modules [WIP] [HELP]
Dynamically buildable/loadable modules that can be used to extend the build system with support for additional languages, code generators, etc.
We need to make the same configuration mechanisms we already use inside the build system available for custom, project-specific configuration.
C++20 modules [WIP] [HELP]
This is an ongoing effort that is currently blocked by support for modules in the compilers.
Specifically, for GCC we have the
cxx-modules-exbranch which implements P1703 and P1842 and which will hopefully be eventually merged with Nathan's branch and/or master. For Clang we are waiting for the module mapper (for header unit and include translation support) as well as some sort of a strict modules mode in the
c++2amode, see this discussion for details. Finally, for MSVC we are waiting for header unit and include translation support hopefully in the form of the module mapper.
If you are working on GCC or Clang and would like to help move things forward on the compilers front, get in touch.
Distributed compilation and caching for C/C++ [WIP]
We already have a lot of the infrastructure work in place. Specifically, all our compilation goes through partial preprocessing (full preprocessing on MSVC) and we have an accurate idea of all the inputs to each translation unit (headers, modules, compiler options, TU tokens themselves, etc) as well as which of them have changed.
Ad hoc build rules
Ability to write custom build rules directly in buildfiles using either a POSIX shell-like subset of portable commands or, for more complex cases, C++.
See issue #24 for some background.
Build system overlays
Ability to overlay a directory tree with buildfiles over a parallel tree with source code. This feature will primarily be helpful while non-intrusively packaging third-party projects.
See issue #26 for some background.
This includes the documentation for the missing pieces of the toolchain itself (mostly the build system) as well as the documentation extraction (from source code) that everyone can use to document their build system modules (and maybe C++ projects in general).
We would like to have the ability to make a configuration hermetic/isolated from outside changes. This functionality would be an additional layer on top of high-fidelity builds that we already have.
We would like the package manager to provide the lockfile functionality.
We would like to have a higher-level (than compiler options) mechanism for specifying the desired configuration.
See issue #11.
Conditional dependencies and package components
This will be our answer to the "How do I only have this dependency on certain platforms (or, more generally, in certain configurations)?" and "How do I make some parts/configurations of my package optional?" type of questions.
See issue #41 for some background.
Support for static analysis [HELP]
We would like to have a general approach for running static analysis tools.
See issue #30 for some background as well as to contribute usage experience, ideas, etc.
We would like to be able to run tests only for targets that have changed. This will rely heavily on our existing work on Testscript, specifically, the fact that the test inputs/outputs are well-encapsulated.
Nice to Have
See the Issues List for some of the nice-to-have features.